From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
Cc: | Joachim Wieland <joe(at)mcknight(dot)de>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: timezones to own config file |
Date: | 2006-06-13 22:15:48 |
Message-ID: | 11006.1150236948@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> What I was thinking is why we couldn't just store the information in a
> global shared system table that is only read on config reload. You
> could have a few columns, maybe the first being a list name, which is
> referenced from a GUC.
Hmmm ... if we keep the notion of a GUC that identifies a set of
compatible timezone names, then a table with a primary key of
(tz_set_name, tz_name) doesn't seem quite so awful. The main
remaining objection I can see is that the postmaster couldn't use
it, only backends. Now this doesn't matter much as far as timestamp
operations go because I don't think the postmaster does any operations
that need TZ data --- but what of verifying that the GUC variable has
a valid value in postgresql.conf at startup? If you're willing to
abandon sanity checking on that string, it might work.
One interesting thought about a system table is that it could be
referenced through a syscache, which'd have the nice property that only
the (probably few) values actually referenced in a given session need to
get loaded.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2006-06-13 22:48:40 | ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) |
Previous Message | Jim C. Nasby | 2006-06-13 21:44:20 | Re: timezones to own config file |