Fabien COELHO <coe...@cri.ensmp.fr> writes:
>> 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?

I think it's entirely silly to be inventing something that's morally a
one-row table, when we already have perfectly good one-row tables.
The value of a server-side variable facility would be mostly that it
doesn't have all the overhead implied by tables.  I think that is a
direct reason not to think about overhead like constraints, as well.

                        regards, tom lane

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to