Hello,
I'm not sure I understand your point. If Oracle provides unsafe package
variables that can fool auditors, it is not a sufficient reason for Pg to
provide the same doubtful feature. And if they have sub-transactions then
their feature may not necessarily be unsafe, at least if the coding is
careful, but this point does not apply to pg.
unsafe is wrong word - are you first man, what I know who are expecting
transactions from variables - the variables are coming from procedural
world - there are not transactions.
We have established that the correctness of the security context use case
presented by Craig requires transactional variables. This is not my fault.
If you present a new feature to implement this use case, then it must
match the case requirements.
your mental model about variables is pretty artificial - it is strange so
Oracle, MSSQL, DB2 30 years didn't find so variables should be
transactional.
As already said, Pg GUCs are transactional, so Pg is out of its mind?
Maybe it is not the case in Oracle when programmed with PL/SQL, then fine.
As I said, your pattern can be correct iff a sub-transaction is used. If
Oracle has sub-stransaction then untransactional variables can be used for
the use case by setting them outside the security verification
transaction. So what is maybe fine in Oracle is not fine with Pg without
subtransactions.
I agree, so there can be some advantages - but I disagree so transactional
is major and required feature.
Hmmm. I strongly oppose adding a feature which does not implement
correctly the use case it is designed for.
There are possible artefacts on border transactional and untransactional
world - so developer should to use patterns that reduces negative
impacts of these artefacts.
I do not think that probabilistic security is a good sales pitch.
Moreover there is no particular issue with implenting the needed feature,
all the mecanism are already available in Pg, so it looks masochistic to
refuse to implement a feature which is already available and happen to be
necessary to the use case correctness.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
