Re: timezones to own config file - Mailing list pgsql-hackers

From Tom Lane
Subject Re: timezones to own config file
Date
Msg-id 23905.1150213885@sss.pgh.pa.us
Whole thread Raw
In response to Re: timezones to own config file  (Martijn van Oosterhout <kleptog@svana.org>)
Responses Re: timezones to own config file  (Martijn van Oosterhout <kleptog@svana.org>)
List pgsql-hackers
Martijn van Oosterhout <kleptog@svana.org> 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.  Getting rid of "australian_timezones" is fine,
but we can't do it by saying "all you aussies have to hack the standard
list according to your own ideas".  I don't expect that very many people
will actually need to make custom timezone name lists --- if we find
they do, we'll need to work harder on the default lists.  So the design
center should be "select one of a few predefined lists", not "hack away
on system catalog until you like it".  Especially not if they have to do
it in template0, template1, postgres, etc.  Basically, a GUC variable is
just about the right paradigm for this, a system catalog isn't.

I'd also be a bit worried about performance issues, eg, whether VACUUM
FULL on such a table would bring datetime operations to a halt.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Rod Taylor
Date:
Subject: Re: CSV mode option for pg_dump
Next
From: Steve Atkins
Date:
Subject: Re: CSV mode option for pg_dump