Hello again,
*** PLEASE, could you remove the parts of emails you are not responding to
when replying in the thread? THANKS. ***
[...] Did I understand?
I guess that the answer is "no":-)
When you are running under only one transaction, then you don't need to
solve reset variables on rollback, because you cannot do anything when
system fails. Only when you are handling a exception, then system
continue, and you can or you cannot to set the variable.
Sorry, I do not understand these sentences.
The usual scenario of using secure content is not related to
transactions - it is related to session. There are two kind of functions
A. slow and expensive that creates secure content/context
B. other that use secure content/context
When you are running A, then some secure context is initialised or it is
invalided. When A fails, then B doesn't work.
Yes, I understand that it is the expected property: B must not work if A
has failed... I'm trying to understand what properties are required on the
session variables wrt to how A ran to achieve this.
When A is successful, then context is valid to another call of A. Next
call of A set context or invalidate context. The transactions play
nothing in this game.
Anything in PostgreSQL is always under a transaction... My concern is for
the following:
-- in a session, there is a transaction
BEGIN;
SELECT A(...);
-- in A:
-- -> check this and that ...
-- -> insert in log ...
-- -> update something else ...
-- -> all seems fine...
-- SET SESSION VARIABLE status_ok = TRUE;
-- -> could do something else...
-- return from A
ROLLBACK;
-- the commit fails, because some differed trigger somewhere is unhappy
-- or the user changed its mind...
Now A has failed, but this could not be known from within the function,
and the status_ok is wrong. If the session proceeds with:
SELECT B();
Then B believes that A succeeded, which is not the case.
The key issue is that the final status (commit or rollback) of the
containing transaction cannot be known from within the function, so the
session variables cannot reflect this status.
So somehow the status_ok variable must be (1) rolledback to previous value
or (2) removed (3) set to FALSE or (4) set to NULL. It cannot be TRUE if A
containing transactions has failed for the security as I understand it.
Maybe it could work with subtransactions: A calls A', A' succeeds (return,
COMMIT is ok), *then* set user_status = ok. The session variables reflects
that A' succeeded, and if A fails later it is ok because the security is
based on the success of A', not the one of A. However, I'm not sure how
subtransactions can be stated simply and within a session in pg.
The content of variable (used in PL) is defined by scope - not by
successful or unsuccessful transactions. The security content will be valid
although user have to do rollback.
I do not understand how the "security context" can be valid of there has
been a rollback which has cancelled all operations: Some log may not have
been written for instance, which would be a key assumption for
establishing the validity of the security context.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
