Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
