because MySQL variables are not declared - and allows assign everywhere -
Ok. I do not do MySQL.
and MSSQL variables are not persistent.
Yep, but they might be?
In one session you can use lot of roles - some code can be used for
securing interactive work, some can be for securing some API, sometimes you
can secure a access to some sources. You can switch lot of roles by using
security definer functions.
Hmmm. Switching role within a transaction. I never did need that... but
that is a use case.
If you need transactional content - then you should to use tables.
Maybe variables just need be a syntactic convenience around that?
There is pretty similar relation between sequences and tables and variables
Yep. A sequence is a one row table, so a variable may be also a one row
table as well, but with more flexibility about its type, and some nice
syntactic sugar (like SERIAL which is syntactic sugar for CREATE SEQUENCE
In first iteration the constraint can be implemented with domains - but
there is not any break to implement constraints directly on variables.
Hmmm. If a variable is implemented as a one row table, then constraints
are already available there, as well as grant & revoke, they can be any
type including composite, nearly nothing to implement to get...
A "one row" table would be a CREATE + one INSERT, UPDATE allowed, further
INSERT and DELETE are disallowed by construction. Then some syntactic
sugar for variables (session => temporary table, persistent => standard
table). Note sure about a "transaction variable", though... maybe an
[unlogged] table automatically dropped on commit?
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: