Re: Surprising behaviour of \set AUTOCOMMIT ON

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Surprising behaviour of \set AUTOCOMMIT ON
Дата
Msg-id CAA4eK1KW-_gT8aJ1qLF6T8q3eC7s8UuY-V6dHNemvmi621uwjA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Surprising behaviour of \set AUTOCOMMIT ON  ("David G. Johnston" <david.g.johnston@gmail.com>)
Список pgsql-hackers
On Sat, Aug 13, 2016 at 1:05 AM, David G. Johnston
<david.g.johnston@gmail.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tatsuo Ishii
Дата:
Сообщение: Re: Slowness of extended protocol
Следующее
От: konstantin knizhnik
Дата:
Сообщение: Re: WIP: Barriers