Re: timezone GUC
От | Magnus Hagander |
---|---|
Тема | Re: timezone GUC |
Дата | |
Msg-id | CABUevEwDXpaC1k8n4hmj=XfdDk0j2u+jXZG436Et+WC4gxA9Aw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: timezone GUC (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: timezone GUC
|
Список | pgsql-hackers |
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/
В списке pgsql-hackers по дате отправления: