According to PostgreSQL’s manual[0]:
“STABLE indicates that the function cannot modify the database, and
that within a single table scan it will consistently return the same
result for the same argument values, but that its result could change
across SQL statements.”
This definition matches both functions. Moreover, find_user_role did
not need to be written in plpgsql, that i assume—but did not test—are
slower than sql functions.
[0]: https://www.postgresql.org/docs/14/sql-createfunction.html
According to the de facto project layout for Go[0], these files should
go into a build/package folder, but since i already broke the rules with
Sqitch’s folders, i do not see why i have to go against Debian’s
conventions of putting it into a debian subfolder of the root.
[0]: https://github.com/golang-standards/project-layout
I’ve tried to make RPM packages of numerus and pgx/v4 for AlmaLinux, so
install in a virtual server, but i was unable to break a build cycle
between golang/x/text, required by pgx, and golang/x/tools both a
dependency and a dependee of golang/x/text: once tools finished
building, it would trigger a new build for text, that in turn would
trigger a build for all its dependences, including tools.
At the end i had to create a Debian repository, because they already
have all the packages, even though i had to back port pgx/v4 from
Testing to bullseye. I did not want to try my luck with writting
packages for pgx/v5, so v4 it is.
This is a very rough test to actually check the login function outside
pgTAP; it is very ugly, in both design and code, and (i hope) does not
reflect future quality.
I was about to use Echo[0] as a “web framework”, but something feels
wrong when using a framework with Go—i do not know what. I actually
tried it and was even more put off by the JSON-formatted logger that can
not be disabled; i was already losing control of the application!
I created the folder following the apparently de facto guidelines for Go
projects, and i see no problem with mixing Go’s folders with Sqitch’s:
both are part of the same application and there are not conflicts.
[0]: https://echo.labstack.com/
[1]: https://github.com/golang-standards/project-layout
User authentication is based on PostgREST’s[0]: There is a noninherit
role, authenticator, whose function is only to switch to a different
role according to the application’s session. Accordingly, this role has
no permission for anything.
The roles that this authentication can switch to are guest, invoicer, or
admin. Guest is for anonymous users, when they need to login or
register; invoicers are regular users; and admin are application’s
administrators, that can change other user’s status, when they have to
be removed or have they password changed, for example.
The user relation is actually inaccessible to all roles and can only be
used through a security definer function, login, so that passwords are
not accessible from the application.
I hesitated on what to use as the user’s primary key. The email seemed
a good candiate, because it will be used for login. But something rubs
me the wrong way.
It is not that they can change because, despite what people on the
Internet keeps parroting, they do not need to be “immutable”, PostgreSQL
can cascade updates to foreign keys, and people do **not** change email
addresses that ofter.
What i **do** know is that email addresses should be unique in order to
be used for login and password, hovewer i had to decide what “unique”
means here, because the domain part is case insensitive, but the local
part who knows? I made the arbitrary decision of assuming that the
whole address is case sensitive.
I have the feeling that this will bite me harder in the ass than using
it as the primary key.
[0]: https://postgrest.org/en/stable/auth.html
jordi fita mas