Re: [HACKERS] proposal: session server side variables

****** PLEASE ******

COULD YOU REMOVE THE PARTS OF EMAILS YOU ARE NOT RESPONDING TO WHEN 
REPLYING IN THE THREAD?

****** THANKS ******

>> [...] Then B believes that A succeeded, which is not the case.
>
> No, just your design is unhappy



> SELECT A(..)
>  SET SESSION VARIABLE status_ok = false;
>  -- do all, if fails there,
>   -- then follow line fails too, or never be executed
>  SET SESSION VARIABLE status_ok = true;

My point is that there is no commit in this code, the commit is performed
*AFTER* the last set session, and it mail fail then.

> or
>
>  SET SESSION VARIABLE status_ok = true
>  TRY
>     do something
>  CATCH
>    ROLLBACK
>    SET SESSION VARIABLE status_ok = false
>
> Both I can do in current PL

The fact that "do something" worked does not preclude the overall 
transaction to work and to revert "do something" and let status_ok as 
true.

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

My point is that A may still fail *after* setting the variable, because it 
is in a transaction.

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

No: This pattern assumes that operations started in the "TRY" zone cannot 
fail later on... This assumption is false because of possible deferred 
triggers for instance. See attached example:

  NOTICE:  SET secured = FALSE
  NOTICE:  SET secured = TRUE
  ERROR:  insert or update on table "log" violates foreign key constraint "log_sid_fkey"
  DETAIL:  Key (sid)=(3) is not present in table "stuff".

The error occurs after secured has been set to TRUE.

-- 
Fabien.
-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers