From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: proposal: session server side variables |
Date: | 2016-12-23 18:39:25 |
Message-ID: | 10933.1482518365@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Fabien COELHO <coelho(at)cri(dot)ensmp(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2016-12-23 18:40:22 | Re: proposal: session server side variables |
Previous Message | Fabien COELHO | 2016-12-23 18:28:07 | Re: proposal: session server side variables |