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...
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
