2017-01-03 15:40 GMT+01:00 Fabien COELHO <coe...@cri.ensmp.fr>:

> 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
>       -- 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.

No, just your design is unhappy

  SET SESSION VARIABLE status_ok = false;
  -- do all, if fails there, then follow line fails too, or never be
  SET SESSION VARIABLE status_ok = true;


  SET SESSION VARIABLE status_ok = true
     do something
   SET SESSION VARIABLE status_ok = false

Both I can do in current PL


> 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.

you don't need do rollback variable if you write well A

> 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.

If you use patterns that I wrote - the security context will be valid

> --
> Fabien.

Reply via email to