Joachim Wieland <[EMAIL PROTECTED]> writes:
> Getting a list of active timezones could be easily done
> with a system view but you might not want to promise its existence when you
> think about moving the whole thing to a system catalog later...
A read-only view wouldn't be a bad idea, actually, f
On Tue, Jun 13, 2006 at 11:11:26PM +0200, Martijn van Oosterhout wrote:
> I think my actual point was something else. We currently get calls from
> people trying to administer machines that it's annoying that various
> configuration information is stored in files, beyond the easy reach of
> SQL.
W
Martijn van Oosterhout 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 not
On Tue, Jun 13, 2006 at 11:11:26PM +0200, Martijn van Oosterhout wrote:
> On Tue, Jun 13, 2006 at 11:51:25AM -0400, Tom Lane wrote:
> > Martijn van Oosterhout writes:
> > > Any particular reason this can't be a normal table in pg_catalog which
> > > you can select/update.
> >
> > That doesn't do
On Tue, Jun 13, 2006 at 11:51:25AM -0400, Tom Lane wrote:
> Martijn van Oosterhout writes:
> > Any particular reason this can't be a normal table in pg_catalog which
> > you can select/update.
>
> That doesn't do anything to help with one of the main problems: that
> we have at least two (maybe m
Martijn van Oosterhout writes:
> Any particular reason this can't be a normal table in pg_catalog which
> you can select/update.
That doesn't do anything to help with one of the main problems: that
we have at least two (maybe more) alternative sets of names that people
might want as default. Get
Joachim Wieland <[EMAIL PROTECTED]> writes:
> The timezone definition files should be read at server start but should they
> also be read at SIGHUP? If so, should they be read only by the postmaster or
> by all backends?
Presumably the name of the definition file to use will be a GUC
variable. I
On Tue, Jun 13, 2006 at 02:20:09PM +0200, Joachim Wieland wrote:
> I looked into the timezone specifications and basically extracted a list of
> existing offsets from the zic database.
>
> My proposed format for the timezone files is something like this:
Any particular reason this can't be a no
I looked into the timezone specifications and basically extracted a list of
existing offsets from the zic database.
My proposed format for the timezone files is something like this:
HADT -32400 D # Hawaii-Aleutain Daylight Time
# (America/Adak)
HAST -36000# Hawaii-Al
Martijn,
On Fri, May 26, 2006 at 03:03:15PM +0200, Martijn van Oosterhout wrote:
> > I think you may be thinking of yet a separate TODO item, which is to
> > be able to use the zic timezone names in timestamptz input, viz
> > '2006-05-24 21:11 Americas/New_York'::timestamptz
> > But names like
On Wed, May 24, 2006 at 09:13:42PM -0400, Tom Lane wrote:
> The zic database doesn't seem to have a problem with using the same
> abbreviations to mean many different things. We could look to it for
> information, or maybe even use its classification of timezone groups,
> but I don't think it can
Joachim Wieland <[EMAIL PROTECTED]> writes:
> I'd like to know what exactly is to be done for this TODO-item
> o Allow customization of the known set of TZ names (generalize the
> present australian_timezones hack)
Well, part of the TODO is to figure out exactly what to do ;-)
> So we'd
I'd like to know what exactly is to be done for this TODO-item
o Allow customization of the known set of TZ names (generalize the
present australian_timezones hack)
The most recent mail in the archives about this subject seems to be:
http://archives.postgresql.org/pgsql-general/2006-04
13 matches
Mail list logo
