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:
http://www.postgresql.org/mailpref/pgsql-hackers
