From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | josh(at)agliodbs(dot)com |
Cc: | Zdenek Kotala <Zdenek(dot)Kotala(at)sun(dot)com>, pgsql-hackers(at)postgresql(dot)org, mledford(at)ugaalum(dot)uga(dot)edu |
Subject: | Re: Daylight Saving Time question PostgreSQL 8.1.4 |
Date: | 2007-03-13 18:14:01 |
Message-ID: | 7680.1173809641@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Josh Berkus <josh(at)agliodbs(dot)com> writes:
> Zdenec,
>> I have following idea:
>> 1) add guc varibale which enable usage of OS time zone files
>> 2) add extra parameters into ./configure script which enable OS TZ
>> support in the code and get path to OS TZ files.
> If we're adding it as a configure-time variable, there's no reason to have
> a GUC.
I see zero reason to have either. It would only make sense to do this
in the context of a platform-specific distribution such as an RPM, and
in that context the simplest solution is to let the RPM specfile make
the substitution (ie, after "make install" and before packaging,
rm -rf PG's timezone tree and insert a symlink). Then it's on the RPM
packager's head whether it's the right thing to do or not. A configure
switch strikes me as mostly a foot-gun, because the average user of
Postgres won't have any way to know whether the files are compatible.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2007-03-13 18:27:17 | Re: My honours project - databases using dynamically attached entity-properties |
Previous Message | Pavan Deolasee | 2007-03-13 18:07:36 | HOT WIP Patch - Version 4.4 |