Re: A bad behavior under autocommit off mode

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > One idea is for SET to return a command tag that has more information,
> > like we do for INSERT/UPDATE/DELETE. It could return the variable
> > modified and the new value.
>
> But that doesn't solve the problem --- what about begin, set, rollback?
> What about absorbing a new value for a variable while re-reading
> postgresql.conf due to SIGHUP?
>
> Unless you want to effectively disable all of the nice GUC behavior
> we've developed, I think you have to have a reporting mechanism that's
> separate from command completion.

Yes, rereading the config file would kill my idea --- but what API are
we going to pass SET to applications? I can't think of a clean method,
yet.

> > Also, are we removing the behavior that SET _doesn't_ start a
> > transaction in autocommit off mode?
>
> If we remove autocommit-off mode, it stops being an issue ;-)

Sure, but how are we going to treat SET in the client?

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073