On Tue, Sep 6, 2011 at 23:52, Robert Haas <robertmh...@gmail.com> wrote: > 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...
+1. I'm not sure I agree it's less DBA-friendly, really - given that it makes it more consistent.. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
