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.1701102136010.11499@lancre
Whole thread Raw
In response to Re: [HACKERS] proposal: session server side variables  (Craig Ringer <craig@2ndquadrant.com>)
List pgsql-hackers
>> 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.
>
> Oh, also, you might want to tell Oracle and the many people who use 
> package variables that.

As it can be used safely with nested transaction, I have no doubt that 
they do that, and that auditors check that carefully when auditing code:-)


> [...] Your unwillingness to listen to anyone else isn't doing your 
> argument any favours though.

Hmmm. I'm far from perfect and I have a limited supply of patience when 
logic does not always apply in a long discussion.

However I think that my review of Pavel proposal is fair, with a clear 
separation of objective (proven) facts and subjective but argumented 
opinions. I do not think that I can contribute anything more by continuing 
argumenting, so I wish I would not have been dragged back into this 
thread:-(

Despite a lot of effort, Pavel proposal is still about a untransactional 
(by default) session variables. Too bad. Time out for me. I'm deeply 
against that, I have said it: I think it would harm PostgreSQL to provide 
such a misleading security feature. Then I'm done. If a committer wants to 
add untransactional session variables with permissions, it is their 
priviledge, and my blessing is not needed anyway.

-- 
Fabien.



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: [HACKERS] CONNECTION LIMIT and Parallel Query don't play well together
Next
From: Fabien COELHO
Date:
Subject: Re: [HACKERS] proposal: session server side variables