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.

Why not.

Maybe variables just need be a syntactic convenience around that?

There is pretty similar relation between sequences and tables and variables
and tables.

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 (
To make changes to your subscription:

Reply via email to