Re: [HACKERS] proposal: session server side variables - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: [HACKERS] proposal: session server side variables
Date
Msg-id alpine.DEB.2.20.1701100655410.849@lancre
Whole thread Raw
In response to Re: [HACKERS] proposal: session server side variables  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] proposal: session server side variables  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: [HACKERS] proposal: session server side variables  (Craig Ringer <craig@2ndquadrant.com>)
Re: [HACKERS] proposal: session server side variables  (Craig Ringer <craig@2ndquadrant.com>)
Re: [HACKERS] proposal: session server side variables  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Hello Robert,

>> Half-persistence (in definition, not in value) is not a key feature 
>> needed by the use-case.
>
> Well, you don't get to decide that.

I do not think that your reprimand is deserved about this point: I did not 
decide a subjective opinion, I noted an objective fact.

> You've been told by at least three or four people that they don't want 
> variables to be transactional, you've been pointed to documentation 
> links showing that in other database systems including Oracle variables 
> are not transactional, and you still insist that this proposal is 
> senseless unless variables are transactional.

Indeed.

I have submitted a proof of this fact in the form of a counter example 
which (1) (pseudo) implements the use-case by logging into an audit table 
the fact a user accesses the secure level (2) shows that the status of a 
non transactional session variable used for keeping this status is wrong 
for the use case in some cases (it says that all is well while appending 
to the audit table failed).

I have also recognized that the use-case could be implemented safely, 
although not correctly, if pg provides nested/autonomous transactions like 
Oracle, DB2 or MS SQL does, but I think that having such a useful feature 
is quite far away...

> You have every right to decide what you think is useful, but you don't 
> have a right to decide what other people think is useful.

Hmmm.

I feel entitled to point out to other people that their belief that a 
feature as described provides a correct solution to a particular use case 
is wrong, if it is factually the case. If they persist in this belief 
despite the submitted proof, I can only be sad about it, because if pg 
provides a feature for a security-relared use case which does not work 
correctly it is just shooting one's foot.

I do not like Pavel's feature, this is a subjective opinion. This feature 
does not provide a correct solution for the use case, this is an objective 
fact. The presented feature does not have a real use case, this is too 
bad.

Finally, I did not "veto" this feature, I reviewed it in depth and 
concluded negatively. You are a committer and I'm just a "silly academic", 
you do not have to listen to anything I say and can take majority votes 
against proofs if you want.

-- 
Fabien.



pgsql-hackers by date:

Previous
From: Dilip Kumar
Date:
Subject: Re: [HACKERS] parallelize queries containing subplans
Next
From: Amit Kapila
Date:
Subject: Re: [HACKERS] Block level parallel vacuum WIP