Granted, but a configure switch would allow users who want to use OS TZ file in conjunction with a compiled from
sourceinstallation. Many users of OSes with package managers such as Debian or RedHat may, for whatever reason, want to
usea source tarball to install and also use the OS TZ list. <br /><br /> That being said, this user group may be small
enoughto ignore. Just throwing it in for thought. <br /><br /> Tom Lane wrote: <blockquote
cite="mid7680.1173809641@sss.pgh.pa.us"type="cite"><pre wrap="">Josh Berkus <a class="moz-txt-link-rfc2396E"
href="mailto:josh@agliodbs.com"><josh@agliodbs.com></a>writes: </pre><blockquote type="cite"><pre wrap="">Zdenec,
</pre><blockquote type="cite"><pre wrap="">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. </pre></blockquote></blockquote><pre wrap=""> </pre><blockquote
type="cite"><prewrap="">If we're adding it as a configure-time variable, there's no reason to have
a GUC. </pre></blockquote><pre wrap="">
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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's
datatypesdo not match
</pre></blockquote>