Tom Lane wrote:
Josh Berkus <email@example.com> 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
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
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:
/opt/dce/lib/zoneinfo HP-UX (no TZif magic word)
/etc/zoneinfo/ Tru64 (no TZif magic word)
<registers> MS Windows
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?