Re: [HACKERS] proposal: session server side variables

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.