| From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
|---|---|
| To: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
| Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com>, Joe Conway <mail(at)joeconway(dot)com> |
| Subject: | Re: proposal: session server side variables |
| Date: | 2017-01-04 11:03:24 |
| Message-ID: | alpine.DEB.2.20.1701041151121.22281@lancre |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>> I respect your opinion and don't agree with it.
>
> Yeah. I'm pretty overwhelmingly unconvinced too.
I'm lost.
The security-related use-case you have presented stores the status of the
verification in a variable. If the variable is untransactional, then it
has been shown that the variable status may say ok while the verification
has really really failed. This means that subsequent operations would be
executed believing wrongly that the security was ok. Not good.
Morover, there is no special cost in implementing transactional on session
variables, has it is already done by pg. It can probably be reused.
An alternative is to implement sub (nested) transactions, like Oracle and
MS SQL Server... but that would be quite some work.
So basically I do not see any point in not doing transactional variables.
--
Fabien.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2017-01-04 11:05:44 | Re: UNDO and in-place update |
| Previous Message | Thomas Munro | 2017-01-04 11:03:10 | Re: Measuring replay lag |