Presently, libpq supports several environment variables (PGTZ,
PGDATESTYLE, etc) which cause it to issue SET commands at the start of a
connection. Since these are plain SETs, they don't affect the session
defaults as far as the backend is concerned. Thus, we get this behavior
as of 7.3:
$ export PGDATESTYLE="postgres"
$ psql regression
regression=# show datestyle; DateStyle
--------------------------------------------Postgres with US (NonEuropean) conventions
(1 row)
regression=# SET DATESTYLE = DEFAULT;
SET
regression=# show datestyle; DateStyle
---------------------------------------ISO with US (NonEuropean) conventions
(1 row)
As part of the 7.4 protocol changes, I've been adjusting libpq and the
backend to send these parameter settings in the initial connection
request packet (so that they don't require extra round trips between
client and server). I was a bit surprised to find this changed the
behavior. The backend treats the parameter settings as coming from the
backend command line, and therefore setting the session default. So I
get:
$ export PGDATESTYLE="postgres"
$ psql regression
regression=# show datestyle; DateStyle
--------------------------------------------Postgres with US (NonEuropean) conventions
(1 row)
regression=# SET DATESTYLE = DEFAULT;
SET
regression=# show datestyle; DateStyle
--------------------------------------------Postgres with US (NonEuropean) conventions
(1 row)
This changes the results of one regression test.
Question: is the old behavior a bug? Or should we preserve it?
I believe it was an implementation artifact, not something anyone
ever thought about carefully. Perhaps we need to keep it on
grounds of backwards compatibility, or perhaps not. I think a good
argument can be made that these settings *should* be treated as the
session defaults.
Comments?
regards, tom lane