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 (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers