| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
| Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, Barry Lind <blind(at)xythos(dot)com>, Neil Conway <neilc(at)samurai(dot)com>, Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: A bad behavior under autocommit off mode |
| Date: | 2003-03-24 19:06:10 |
| Message-ID: | 19343.1048532770@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
> 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 ;-)
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2003-03-24 19:08:34 | Re: 7.4devel auth failed |
| Previous Message | Merlin Moncure | 2003-03-24 19:03:29 | Re: MySQL at .NET conference |