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 15:51:25
Message-ID: 23905.1150213885@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:
> 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Brandon E Hofmann 2006-06-13 16:08:50 Please help!
Previous Message Rod Taylor 2006-06-13 15:30:56 Re: CSV mode option for pg_dump