Re: timezones to own config file

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

In response to

Browse pgsql-hackers by date

  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