On Tue, Sep 6, 2011 at 5:16 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > 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.
Seems reasonable to me... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
