From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Joe Conway <joe(dot)conway(at)credativ(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: psql -c does not honor ON_ERROR_STOP |
Date: | 2015-01-06 18:36:29 |
Message-ID: | 15380.1420569389@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Joe Conway <joe(dot)conway(at)credativ(dot)com> writes:
> This seems like either a psql bug or maybe just a documentation bug. I
> know the psql docs say that -c behavior can be surprising, but I find
> the below surprising even after reading the docs a couple of times.
> Given that ON_ERROR_STOP defaults to off, it seems like these two
> cases should both result in two rows inserted.
-c submits the entire string to the backend in one PQexec(); therefore
ON_ERROR_STOP cannot have any impact on its behavior. The backend will
abandon processing the whole string upon first error, embedded begin/
commit commands notwithstanding.
There's been repeated discussion of changing -c so that the string is
split apart and processed more like it would be if it'd been read from
stdin. However, given the number of ways you can already submit a
string via stdin, this wouldn't be buying any new functionality. Even
discounting backwards-compatibility considerations, such a change would
make it completely impossible to test multiple-commands-per-PQexec
scenarios using psql. So I'm inclined to leave it alone.
Possibly the point is worth documenting explicitly, though.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2015-01-06 18:46:57 | Re: Re: [COMMITTERS] pgsql: Change how first WAL segment on new timeline after promotion is |
Previous Message | Joe Conway | 2015-01-06 18:28:48 | psql -c does not honor ON_ERROR_STOP |