Tom Lane wrote:
> Josh Berkus <josh@agliodbs.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.
I don't think to make a symlink is good solution. It generates a lot of
future problem with package update or patching. Configure switch is much
comfortable for packagers/patch makers. In case when average user want
to compile own postgres we can offer regression test focused on TZ
validation. (By the way average user is surprise, that postgres has own
zone files)
I also think, usage system's timezone files should be by default and
configure script determines zonefiles location based on OS. Another
location could be set by switch. If for some platform will be necessary
use own copy, special switch (e.g. --enable-internal-tzfiles) setup
postgres for process own timezone copy.
Zdenek
PS: For information there are TZ locations on several OS:
/usr/share/lib/zoneinfo Solaris
/usr/share/zoneinfo Redhat
/opt/dce/lib/zoneinfo HP-UX (no TZif magic word)
/etc/zoneinfo/ Tru64 (no TZif magic word)
/usr/share/zoneinfo/ MacOS
<registers> MS Windows
