Re: [HACKERS] proposal: session server side variables
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] proposal: session server side variables |
Дата | |
Msg-id | 10933.1482518365@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] proposal: session server side variables (Fabien COELHO <coelho@cri.ensmp.fr>) |
Ответы |
Re: [HACKERS] proposal: session server side variables
|
Список | pgsql-hackers |
Fabien COELHO <coelho@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
В списке pgsql-hackers по дате отправления: