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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to