OS timezone files support

This patch brings possibility to switch from default build-in timezone
to another timezone source - typically to OS timezone location. This
enhancement helps to packagers easy solve integration problem with
systems Timezones.

If --with-tzdir=/usr/share/zoneinfo is specified as ./configure
parameter, postgres will use timezone files from /usr/share/zoneinfo
directory and build-in timezone files will not be installed by make
install command.

It was discussed few weeks ago:

http://archives.postgresql.org/pgsql-hackers/2007-03/msg00784.php

With regards Zdenek

Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> writes:
> This patch brings possibility to switch from default build-in timezone
> to another timezone source - typically to OS timezone location.

> It was discussed few weeks ago:
> http://archives.postgresql.org/pgsql-hackers/2007-03/msg00784.php

AFAIR, the conclusion of that discussion was we didn't want it.

I certainly don't see the point of the implementation as you have it
--- it adds a great deal of unnecessary infrastructure compared to just
installing a symlink at share/postgresql/timezone.

regards, tom lane

Tom Lane wrote:
> Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> writes:
>> This patch brings possibility to switch from default build-in timezone
>> to another timezone source - typically to OS timezone location.
>
>> It was discussed few weeks ago:
>> http://archives.postgresql.org/pgsql-hackers/2007-03/msg00784.php
>
> AFAIR, the conclusion of that discussion was we didn't want it.
>
> I certainly don't see the point of the implementation as you have it
> --- it adds a great deal of unnecessary infrastructure compared to just
> installing a symlink at share/postgresql/timezone.

And if you wanted it in the backend instead of a symlink, shouldn't it
at least try to verify that the files in the timezone directory are
compatible before blindly accepting it?

//Magnus

Tom Lane wrote:
> Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> writes:
>> This patch brings possibility to switch from default build-in timezone
>> to another timezone source - typically to OS timezone location.
>
>> It was discussed few weeks ago:
>> http://archives.postgresql.org/pgsql-hackers/2007-03/msg00784.php
>
> AFAIR, the conclusion of that discussion was we didn't want it.

I'm sorry, but I don't think that the thread has clear conclusion.

> I certainly don't see the point of the implementation as you have it
> --- it adds a great deal of unnecessary infrastructure compared to just
> installing a symlink at share/postgresql/timezone.

The point of my solution is that all packagers who interested in use
only configure switch instead of playing with link integration. In this
case, Packager also must cleanup build-in timezones after make install.
This is not only about add one line into spec file.

There is also big risk that new version of package which will delivery
timezones can replace system file zone information and it damages a system.

I discussed it with gatekeepers which are responsible for patch
preparation and they afraid about future problems with link solution
(based on experience with another sw integration).

with regards Zdenek

Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> writes:
> Tom Lane wrote:
>> I certainly don't see the point of the implementation as you have it
>> --- it adds a great deal of unnecessary infrastructure compared to just
>> installing a symlink at share/postgresql/timezone.

> The point of my solution is that all packagers who interested in use
> only configure switch instead of playing with link integration. In this
> case, Packager also must cleanup build-in timezones after make install.
> This is not only about add one line into spec file.

No, it's two lines (rm -rf, ln -s). It'll take many more lines than
that to do it in the Postgres configure/build system, even using the
simpler symlink approach. And quite aside from the code addition, what
of documentation? How much text will it take to make clear what this
switch is good for and when it's safe to use?

I just don't see the value of supporting this option in our
configuration infrastructure. Anyone who is competent to determine
whether it's a safe thing to use is more than competent to alter the
installation that way for themselves.

regards, tom lane

Magnus Hagander wrote:
> Tom Lane wrote:
>> Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> writes:
>>> This patch brings possibility to switch from default build-in timezone
>>> to another timezone source - typically to OS timezone location.
>>> It was discussed few weeks ago:
>>> http://archives.postgresql.org/pgsql-hackers/2007-03/msg00784.php
>> AFAIR, the conclusion of that discussion was we didn't want it.
>>
>> I certainly don't see the point of the implementation as you have it
>> --- it adds a great deal of unnecessary infrastructure compared to just
>> installing a symlink at share/postgresql/timezone.
>
> And if you wanted it in the backend instead of a symlink, shouldn't it
> at least try to verify that the files in the timezone directory are
> compatible before blindly accepting it?

I think that packager is responsible for verification his integration.
It is same in both cases (configure or link solution). I'm not sure if
it is necessary make check of timezone validity during build time. Build
environment should be different from target system.

If you talk about checking timezone files on runtime, I hope Postgres
verify timezone files every time.

Zdenek

Tom Lane wrote:
> Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> writes:
>> Tom Lane wrote:
>>> I certainly don't see the point of the implementation as you have it
>>> --- it adds a great deal of unnecessary infrastructure compared to just
>>> installing a symlink at share/postgresql/timezone.
>
>> The point of my solution is that all packagers who interested in use
>> only configure switch instead of playing with link integration. In this
>> case, Packager also must cleanup build-in timezones after make install.
>> This is not only about add one line into spec file.
>
> No, it's two lines (rm -rf, ln -s). It'll take many more lines than
> that to do it in the Postgres configure/build system, even using the
> simpler symlink approach. And quite aside from the code addition, what
> of documentation? How much text will it take to make clear what this
> switch is good for and when it's safe to use?
>
> I just don't see the value of supporting this option in our
> configuration infrastructure. Anyone who is competent to determine
> whether it's a safe thing to use is more than competent to alter the
> installation that way for themselves.

I thought about it and You are right. It is really better to keep
solution on packagers, than extend infrastructure and give "machine gun"
to everybody :-).

Thanks for your time

Zdenek