Re: proposal: session server side variables

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Joe Conway <mail(at)joeconway(dot)com>
Subject: Re: proposal: session server side variables
Date: 2017-01-10 22:09:36
Message-ID: alpine.DEB.2.20.1701102223060.11499@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Verite 2017-01-10 22:33:17 Re: pg_dump / copy bugs with "big lines" ?
Previous Message Fabien COELHO 2017-01-10 21:22:43 Re: proposal: session server side variables