Re: [HACKERS] proposal: session server side variables - Mailing list pgsql-hackers

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