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@gmx.net
