Re: Review: pre-commit triggers

On 11/19/2013 10:58 AM, Robert Haas wrote:
> On Mon, Nov 18, 2013 at 9:39 AM, Ian Lawrence Barwick <barwick@gmail.com> wrote:
>>    postgres=# BEGIN ;
>>    BEGIN
>>    postgres=*# INSERT INTO foo (id) VALUES (1);
>>    INSERT 0 1
>>    postgres=*# COMMIT ;
>>    NOTICE:  Pre-commit trigger called
>>    ERROR:  relation "bar" does not exist
>>    LINE 1: SELECT foo FROM bar
>>   ^
>>    QUERY:  SELECT foo FROM bar
>>    CONTEXT:  PL/pgSQL function pre_commit_trigger() line 4 at EXECUTE statement
>>    postgres=#
>>
>> I'd expect this to lead to a failed transaction block,
>> or at least some sort of notice that the transaction itself
>> has been rolled back.
> Ending up in a failed transaction block would be wrong.  If the user
> does a BEGIN, a bunch of stuff, and a COMMIT, they're entitled to
> assume without checking that they are no longer in a transaction
> block.  The COMMIT may have actually performed a ROLLBACK, but one way
> or the other the transaction block will have ended.  This is important
> for things like psql <
> my-dumb-script-with-several-begin-commit-blocks.
>
> It is a little less clear whether it's best for the COMMIT to return
> an ERROR message or something else, but I think the ERROR is probably
> the best solution.  There is already commit-time code that can fail
> today, so there should be precedent here.  And I suspect anything
> other than ERROR will be really messy to implement.
>



OK, you've convinced me.

cheers

andrew