Re: Surprising behaviour of \set AUTOCOMMIT ON
От | Robert Haas |
---|---|
Тема | Re: Surprising behaviour of \set AUTOCOMMIT ON |
Дата | |
Msg-id | CA+TgmoYvtXrOK7UFBVKKKPdRSLTtAOztxoj3wDJ0zRbGN-8tQg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Surprising behaviour of \set AUTOCOMMIT ON (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Surprising behaviour of \set AUTOCOMMIT ON
|
Список | pgsql-hackers |
On Thu, Sep 15, 2016 at 11:10 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Thu, Sep 15, 2016 at 7:29 AM, Rahila Syed <rahilasyed90@gmail.com> wrote: >>> In keeping with current design of hooks instead of rejecting autocommit 'ON' >>> setting inside >>> a transaction,the value can be set to 'ON' with a psql_error displaying that >>> the value >>> will be effective when the current transaction has ended. > >> Hmm, that seems like a reasonable compromise. > > I dunno, implementing that seems like it will require some very fragile > behavior in the autocommit code, ie that even though the variable is "on" > we don't do anything until after reaching an out-of-transaction state. > It might work today but I'm afraid we'd break it in future. Hmm, I don't think any logic change is being proposed, just a warning that it may not work the way you think. So I don't think it would be any more fragile than now. Am I missing something? > I think changing the hook API is a pretty reasonable thing to do here > (though I'd make it its own patch and then add the autocommit change > on top). When was the last time you actually wanted to set VERBOSITY > to "fubar"? I agree that'd be better but I don't know that we should expect Rahila to do that as a condition of getting a usability warning accepted. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: