Re: psql swallowed my "BEGIN;" on reset... user beware?

From: Ken Tanzer <ken(dot)tanzer(at)gmail(dot)com>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: Moshe Jacobson <moshe(at)neadwerx(dot)com>, PG-General Mailing List <pgsql-general(at)postgresql(dot)org>
Subject: Re: psql swallowed my "BEGIN;" on reset... user beware?
Date: 2013-09-30 23:23:58
Message-ID: CAD3a31XtkWNFnzPHHfasZFDTZPyVTp-nFxaTEX-bYR2DwH1nTw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

>
> you can control this with on error stop directive -- add it to your
> psqlrc if you want the setting to persist.

I hear what you're saying, but wonder about the implications:

It sounds like you can't trust your BEGIN to actually start a transaction
unless on_error_stop is set

The default for on_error_stop seems to be off, so at a minimum this is a
default gotcha waiting to happen. At the very least, perhaps the
documentation for BEGIN and ON_ERROR_STOP should mention this?

Should BEGIN be a special case? The operator clearly wants the subsequent
commands to run together or not at all. I'm having trouble imagining any
scenario under which one would want their commands to continue after a
failed BEGIN, especially if it happens at random times outside of one's
control.

Is your response based on belief that the current behavior is good, or a
concern about changing the way psql works, or undesired side effects from
changing it? I could understand any of those--just curious what your
thinking is!

Cheers,
Ken

In response to

Browse pgsql-general by date

  From Date Subject
Next Message akp geek 2013-10-01 02:14:53 Postgres replication question :- One master 2 slaves 9.0.10
Previous Message Tom Lane 2013-09-30 21:33:32 Re: Inconsistent behavior with unnamed columns