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.