Re: psql metaqueries with \gexec
| От | Corey Huinker | 
|---|---|
| Тема | Re: psql metaqueries with \gexec | 
| Дата | |
| Msg-id | CADkLM=fEFM5sAoi2p+jx_A_wEHYpBmvfbHwpvbUEyP2wpOKCXA@mail.gmail.com обсуждение исходный текст | 
| Ответ на | Re: psql metaqueries with \gexec ("Daniel Verite" <daniel@manitou-mail.org>) | 
| Ответы | Re: psql metaqueries with \gexec | 
| Список | pgsql-hackers | 
On Mon, Feb 22, 2016 at 10:08 AM, Daniel Verite <daniel@manitou-mail.org> wrote:
Corey Huinker wrote:
> ...and query text visibility, and result visibility, and error handling,
> etc. In this case, we're leveraging the psql environment we'd already set
> up, and if there's an error, \set ECHO queries shows us the errant SQL as
> if we typed it ourselves..
BTW, about error handling, shouldn't it honor ON_ERROR_STOP ?
With the patch when trying this:
=> set ON_ERROR_STOP on
=> select * from (values ('select 1/0', 'select 1/0')) AS n \gexec
it produces two errors:
ERROR: division by zero
ERROR: division by zero
I'd rather have the execution stop immediately after the first error,
like it's the case with successive queries entered normally via the
query buffer:
=> \set ON_ERROR_STOP on
=> select 1/0; select 1/0;
ERROR: division by zero
as opposed to:
=> \set ON_ERROR_STOP off
=> select 1/0; select 1/0;
ERROR: division by zero
ERROR: division by zero
Yes, I would like it to honor ON_ERROR_STOP. I'll look into that.
В списке pgsql-hackers по дате отправления: