I wrote:
> Robert Haas <robertmh...@gmail.com> writes:
>> I am (and, I think, Alvaro is also) of the opinion that the behavior
>> here is still not really right.
> I don't see a practical way to do better unless we can find a less
> horridly inefficient way of implementing identify_system_timezone().
Although there's always more than one way to skin a cat. Consider
this idea:
1. The hard-wired default for timezone is always UTC (or something
else not dependent on environment).
2. We put the identify_system_timezone work into initdb, and have it
inject a non-default entry into postgresql.conf in the usual way
if it can identify what the system zone is.
3. Run-time dependency on TZ environment disappears altogether.
This basically means that instead of incurring that search on every
postmaster start, we do it once at initdb. If you change the
postmaster's timezone environment, well, you gotta go change
postgresql.conf.
IMO this would be less DBA-friendly in practice, but only very
marginally so; and getting rid of the special initialization behavior of
the timezone GUC might well be considered sufficient recompense.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
