Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > We can just say, "Don't alter the client encoding behind the back of the
> > driver."
>
> We can perhaps get away with saying that for client_encoding, but what
> of DateStyle? "SET" has been the traditional way to adjust that since
> the stone age.
>
> It seems to me there is not a lot of distance between what I originally
> suggested (transmit values of interesting variables at connection start)
> and what we're talking about here (transmit values of interesting
> variables at connection start and then again if they change). I'm more
> than willing to do the small amount of additional work needed, if it
> makes interface libraries' job easier.
I have been thinking about this SET thing, and here are some more ideas.
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. Of course, that doesn't help with SET
inside transactions because it is only the COMMIT where it should show.
One idea there is for COMMIT to indicate that _some_ SET variable was
changed, and the client has to query the backend for each value it is in
interested in. There is also RESET to deal with, and RESET ALL, which
could change multiple SET values.
For autocommit on the client side, I assume folks realize that the
clients are going to have to parse the query string to find out if BEGIN
is needed, e.g.:
INSERT;COMMIT;INSERT;COMMIT
It will have to deal with quote detection and backslash handling, e.g.
\; doesn't terminate a query, I think.
Also, are we removing the behavior that SET _doesn't_ start a
transaction in autocommit off mode? As I remember, autocommit was the
primary reason we wanted that behavior, and with no SET AUTOCOMMIT, it
seems strange.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
