From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Rahila Syed <rahilasyed90(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Surprising behaviour of \set AUTOCOMMIT ON |
Date: | 2016-08-17 13:01:23 |
Message-ID: | CA+TgmobaO8UC5kLjoO4E9H+4URJ_mxnatMM-ShnzC3pxqAmpUQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Aug 16, 2016 at 5:25 PM, Rahila Syed <rahilasyed90(at)gmail(dot)com> wrote:
>>I think I like the option of having psql issue an error. On the
>>server side, the transaction would still be open, but the user would
>>receive a psql error message and the autocommit setting would not be
>>changed. So the user could type COMMIT or ROLLBACK manually and then
>>retry changing the value of the setting.
>
> Throwing psql error comes out to be most accepted outcome on this thread. I
> agree it is safer than guessing user intention.
>
> Although according to the default behaviour of psql, error will abort the
> current transaction and roll back all the previous commands.
A server error would do that, but a psql errror won't.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Gierth | 2016-08-17 13:12:09 | Re: EXLCUDE constraints and Hash indexes |
Previous Message | Anastasia Lubennikova | 2016-08-17 13:01:20 | Re: Pluggable storage |