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.1701102223060.11499@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
List pgsql-hackers
Hello Robert,

> You're just ignoring explanations from other people - Craig in
> particular - about why it DOES satisfy their use case.

I'm not so sure about Craig precise opinion, but I cannot talk in his 
name. I think that I understood that he points out that there exists a 
situation where the use case is okay despite an untransactional variable: 
if the containing transaction is warranted not to fail, and probably 
(provably?) a read-only transaction is enough for that. Okay, sure...

This falls under "the feature works sometime", which I think is not 
acceptable for a security thing in pg core.

> And the reason his argument is valid is because he is questioning your 
> premise. [...]

Yes.

I made the assumption that PostgreSQL is about keeping data safe and 
secure, and that misleading features which do not comply with this goal 
should be kept out.

This is indeed a subjective opinion, not provable truth.

I only assumed that this opinion was implicitely shared, so that providing 
a counter example with the feature where data is not safe or secure was 
enough to dismiss the proposal.

I'm clearly wrong: some people are okay with a security feature proven not 
to work in some case, if it works for their particular (read-only) case.

>> 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.
>
> If the presented feature had no use case, I don't think there would be
> 3 or 4 people arguing for it.  Those people aren't stupid.

I have not said that, nor thought that.

I pointed out my arguments, basically I answer "security must always work" 
to "the feature can work sometimes". Then it cycles. As I can offer 
limited time for reviewing features, at some point I do not have any more 
time to argue constructively and convince people, that is life. That is 
when I tried to conclude my contribution by sending my review.

> [..] Are you also willing to accept other people's differing 
> conclusions?

I do not have to "accept", or not, differing conclusions. The committer 
decides in the end, because they have the power, I just have words.

All I can say is that as a committer I would not commit such a feature.

As a basic contributor, I can hope that the best decision is made in the 
end, and for that I try to express arguments precisely and objectively, 
that is the point of reviewing a proposal and give advice about how it 
should be amended if I think it should.

> I believe that the words "silly" and "academic" were used about certain 
> proposals that you made, [..] it does necessarily imply personal 
> disrespect.

Sure. "Silly academic" suits me though, I'm fine with it:-)

-- 
Fabien.



pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: [HACKERS] proposal: session server side variables
Next
From: "Daniel Verite"
Date:
Subject: Re: [HACKERS] pg_dump / copy bugs with "big lines" ?