Re: A bad behavior under autocommit off mode

Tom Lane writes:

> 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.

The JDBC driver sets the datestyle on startup and there's no reason why a
client application would explicitly want to change it to defeat the JDBC
driver. So "don't do that" applies here as well.

It could be helpful to have a command to set a value and not allow it to
be changed afterwards. But are there *real* applications where it would
make a difference?

And where does it stop? There are about a dozen GUC variables that will
break an application as a whole if they don't have the value expected by
the application. Do we need to install guards against all of these?

> 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 thought the originally proposed transmission was from the client to the
server (client encoding, time zone) whereas this transmission would be
from the server to the client.

--
Peter Eisentraut peter_e(at)gmx(dot)net