Re: proposal: session server side variables

Hello Craig.

>> 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...
>
> No.
>
> I'm saying that if you do a series of checks, then set the variable
> last, it does not matter if the xact somehow aborts after setting the
> variable. You have already done all your checks and are satisfied that
> the user has the appropriate access level.

I'm lost. This is precisely what I had in mind above with "read-only
transaction" which is "warranted not to fail". I do not understand about
which point you write "No".

>> 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.
>
> [...] Sometimes compromises are a thing.

Indeed. Sequence is an interesting compromise with a clear use case and a
measurable performance impact resulting from this. Note that sequences do
have a key transactional property: it is transactionaly warranted that
distinct committed transactions, whenever they occur (simultaneously or
after a crash), get distinct values (bar cycles, sure).

IMHO, security & compromise do not work well together, so should be
avoided. I recognize that this is an opinion.

As for the particular case, there is no deep problem about session
variables being transactional: The available ones already have this
property. They are pretty fast (eg 0.186 µs/get + cast to int on my
laptop, or 5.3 million retrieval per second).

I'm yet to understand how compromising security is worth the added value
of the discussed proposal. It is not about performance. The static
checkability is moot. I have already argued about all that...

> Now, I have already said that I actually agree that transactional vars
> are probably a good default and something we should have if we do this.

Yep, I read that. Pavel updated proposal does not do that.

Are you "voting" for or against the proposal?

ISTM that you are currently counted as "for".

> But they are not the One True And Only Way.

Indeed. The idea that security & compromise do not go well together is an
opinion, and people may feel that a security feature can be compromised.

We could add a "maybe corrupt the database" feature because it provides
better performance to some use case: MySQL has made this initial choice
that performance is better than data safety, with great popular success.

I do not think that pg should fellow such path, the product is not on the
same market. I understood that data safety & security are key properties
expected of PostgreSQL and that it should remain a goal of the project.
You can call this hyperbolic, or a misunderstanding, but that is the
position I am defending on this thread.

>> 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.
>
> Many normal things work only in some cases.
>
> COMMIT can be indeterminate if you lose your connection after sending
> COMMIT and before getting a reply.

The commit *is* determinate on the server. Knowing whether it succeeded by
a client is indeed indeterminate because the message saying so may be
lost, as you point out.

> So. I would like transactional variables and think you have made a
> good case for them.

I'm not that sure:-)

> If they prove impractical, [...]

ISTM that I have also shown that they are practical, so there is no good
reason to compromise.

--
Fabien.