Re: [HACKERS] [PATCHES] Time zone definitions to config files
On Tue, Jul 25, 2006 at 10:37:20PM -0400, Tom Lane wrote: David Fetter [EMAIL PROTECTED] writes: I'll take a whack at that patch this evening PDT or tomorrow evening at the latest. We're too late in the cycle to go over this, but maybe we can figure out a way to have this data read from the same data source as the pg_timezones VIEW does at compile time. Keeping two such table in synch seems error-prone. Well, the problem is exactly that there is no same data source anymore: the local DBA can customize the timezone list all he wants. We could document what the out-of-the-box settings are, but is it really useful to duplicate that info in the SGML docs? We don't for example provide a copy of psql \df+ output in the SGML docs, and I'm wondering if this isn't kind of the same animal. I'd vote for not including it. The current table is way out of sync already. I first chose the timezones for the Default-set based on this table in the docs but then I noticed that the table does not really reflect the timezones in the source code. With the view it's now almost trivial to keep both synced but it still is a source of errors. Furthermore since nobody has complained about the incorrect table so far, I don't think many people care. And those who do can easily consult the view or the file of the Default set directly. Joachim ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [PATCHES] Time zone definitions to config files
David Fetter [EMAIL PROTECTED] writes: On Mon, Jul 24, 2006 at 11:59:34PM -0400, Tom Lane wrote: The documentation is still in need of help ... in particular, Table B-4 (timezone names) is now out of sync with reality. I'll take a whack at that patch this evening PDT or tomorrow evening at the latest. We're too late in the cycle to go over this, but maybe we can figure out a way to have this data read from the same data source as the pg_timezones VIEW does at compile time. Keeping two such table in synch seems error-prone. Well, the problem is exactly that there is no same data source anymore: the local DBA can customize the timezone list all he wants. We could document what the out-of-the-box settings are, but is it really useful to duplicate that info in the SGML docs? We don't for example provide a copy of psql \df+ output in the SGML docs, and I'm wondering if this isn't kind of the same animal. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
