Re: timezone GUC
| От | Tom Lane |
|---|---|
| Тема | Re: timezone GUC |
| Дата | |
| Msg-id | 6146.1315430168@sss.pgh.pa.us обсуждение |
| Ответ на | Re: timezone GUC (Magnus Hagander <magnus@hagander.net>) |
| Ответы |
Re: timezone GUC
|
| Список | pgsql-hackers |
Magnus Hagander <magnus@hagander.net> writes:
> 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:
>>> 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.
>> Seems reasonable to me...
> +1.
I spent a bit of time on this idea last night. The most painful part
actually seems to be translating identify_system_timezone to run in a
non-backend environment (no elog, etc). The one thing I've run into
that doesn't seem straightforward is to decide where to look for the
timezone files. If we have --with-system-tzdata then of course it's a
constant, but should we honor initdb's -L switch otherwise? And if so,
how should we pass that into the pg_TZDIR code?
regards, tom lane
В списке pgsql-hackers по дате отправления: