Tom Lane wrote:
Josh Berkus <> writes:
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.


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

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?


Reply via email to