Hello Craig,
I have submitted a proof of this fact in the form of a counter example which
(1) (pseudo) implements the use-case by logging into an audit table the fact
a user accesses the secure level (2) shows that the status of a non
transactional session variable used for keeping this status is wrong for the
use case in some cases (it says that all is well while appending to the
audit table failed).
You've been assuming everyone else cares about auditing such access
into a table.
No, I have not.
For the PosgreSQL product, I'm really assuming that a security feature
should work in all cases, not just some cases with implicit uncheckable
restrictions, especially restrictions related to transactions which is all
a database is about. I think that providing a misleading feature is a bad
idea.
Note that my blessing is not required. If a committer wants to add this
then they can do it.
But you're fixated on the idea that without that use case satisfied the
rest is useless, and that's simply not the case. Transactional vars are
only needed if you make _write_ changes to the DB that must be committed
atomically with the var change. If you're only doing (maybe expensive)
lookups, it doesn't matter.
It does not matter if and only if the transaction does not fail, not
because the variable is not transactional. Basically, if it is
untransactional, then it works only if it behaves exactly like a
transaction...
Again ... I think you've assumed everyone else is talking about the
same security-related case you are.
I'm looking forward to see any use case which requires untransactional
variables with permissions and works correctly without adding un-database
constraints such as "please do not use in transactions that change any
data because then it may or may not work".
It's kind of like someone coming to you and saying they want to add an
engine to their glider, and you explaining that it's totally useless
to add an engine unless it can also function as a submarine. Um,
that's nice, but not what they asked for.
Hmmm... I think that it is really like adding an engine on a glider which
does not work if the glider flies under a cloud. You just have to recall
that you should not fly under a cloud when the engine is turned on.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
