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
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 |