On Tue, Sep 6, 2011 at 23:52, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Sep 6, 2011 at 5:16 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I wrote:
>>> Robert Haas <robertmhaas@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/