Re: Surprising behaviour of \set AUTOCOMMIT ON

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Venkata Balaji N <nag1010(at)gmail(dot)com>, Rahila Syed <rahilasyed90(at)gmail(dot)com>, Matt Kelly <mkellycs(at)gmail(dot)com>, Brendan Jurd <direvus(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Surprising behaviour of \set AUTOCOMMIT ON
Date: 2016-08-14 05:03:23
Message-ID: CAA4eK1KW-_gT8aJ1qLF6T8q3eC7s8UuY-V6dHNemvmi621uwjA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Aug 13, 2016 at 1:05 AM, David G. Johnston
<david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
>
> I'll admit I haven't tried to find fault with the idea (or discover better
> alternatives) nor how it would look in implementation. As a user, though,
> it would make sense if the system behaved in this way. That only AUTOCOMMIT
> needs this capability at the moment doesn't bother me. I'm also fine with
> making it an error and moving on - but if you want to accommodate both
> possibilities this seems like a cleaner solution than yet another
> environment variable that a user would need to consider.
>

I agree on your broad point that we should consider user convenience,
but in this case I am not sure if it will be convenient for a user to
make the behaviour dependent on value of ON_ERROR_STOP. I have
checked this behaviour in one of the top commercial database and it
just commits the previous transaction after the user turns the
Autocommit to on and the first command is complete. I am not saying
that we should blindly follow that behaviour, but just to indicate
that it should be okay for users if we don't try to define multiple
behaviours here based on value of ON_ERROR_STOP.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Aravind Kumar 2016-08-14 05:54:45 numeric data type upper limit.
Previous Message Tatsuo Ishii 2016-08-14 01:47:06 Re: Slowness of extended protocol