On ons, 2011-09-07 at 17:16 -0400, Tom Lane wrote: > Magnus Hagander <mag...@hagander.net> writes: > > On Tue, Sep 6, 2011 at 23:52, Robert Haas <robertmh...@gmail.com> wrote: > >> On Tue, Sep 6, 2011 at 5:16 PM, Tom Lane <t...@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 >
It looks like the --with-system-tzdata case is somewhat broken now in initdb: creating configuration files ... could not open directory "...../pg-install/share/timezone": No such file or directory ok -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
