Commit Graph

4 Commits

Author SHA1 Message Date
jordi fita mas 27af39b296 Add the Catalonia’s Tourism Registry number to company
It is required to be displayed on the website of tourism companies of
Catalonia.
2023-10-14 21:59:36 +02:00
jordi fita mas 3768dd5082 Replace serial columns with ‘generated by default as identity’
I just found out that this is a feature introduced in PostgreSQL 10,
back in 2017.

Besides this being the standard way to define an “auto incremental
column” introduced in SQL:2003[0], called “identity columns”, in
PostgreSQL the new syntax has the following pros, according to [1]:

 * No need to explicitly grant usage on the generated sequence.
 * Can restart the sequence with only the name of the table and column;
   no need to know the sequence’s name.
 * An identity column has no default, and the sequence is better
   “linked” to the table, therefore you can not drop the default value
   but leave the sequence around, and, conversely, can not drop the
   sequence if the column is still defined.

Due to this, PostgreSQL’s authors recommendation is to use identity
columns instead of serial, unless there is the need for compatibility
with PostgreSQL older than 10[2], which is not our case.

According to PostgreSQL’s documentation[3], the identity column can be
‘GENERATED BY DEFAULT’ or ‘GENERATED ALWAYS’.  In the latter case, it is
not possible to give a user-specified value when inserting unless
specifying ‘OVERRIDING SYSTEM VALUE’.  I think this would make harder to
write pgTAP tests, and the old behaviour of serial, which is equivalent
to ‘GENERATED BY DEFAULT’, did not bring me any trouble so far.

[0]: https://sigmodrecord.org/publications/sigmodRecord/0403/E.JimAndrew-standard.pdf
[1]: https://www.2ndquadrant.com/en/blog/postgresql-10-identity-columns/
[2]: https://wiki.postgresql.org/wiki/Don't_Do_This#Don.27t_use_serial
[3]: https://www.postgresql.org/docs/15/sql-createtable.html
2023-09-26 19:35:16 +02:00
jordi fita mas 866af09b50 Move the user role down to company_user relation
I was starting to add the public page for campsite types, creating more
granular row-level security policies for select, insert, update, and
delete, because now the guest users needed to SELECT them and they have
no related company to filter the rows with.  Suddenly, i realized that
the role was wrong in the user relation: a user can be an admin to one
company, and employee to another, and guess to yet another company;
the role should be in the company_user relation instead.

That means that to know the role to set to, the user alone is not enough
and have to know the company as well.  Had to change all the
cookie-related function to accept also the company’s host name, as this
is the information that the Go application has.
2023-08-08 02:22:16 +02:00
jordi fita mas 4bf8b0bf0d Add company and company_user relations, along with their dependencies 2023-07-29 04:25:56 +02:00