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 по дате отправления: