Re: [PATCHES] OS timezone files support
Tom Lane wrote: Zdenek Kotala [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] OS timezone files support
Zdenek Kotala [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] OS timezone files support
Tom Lane wrote: Zdenek Kotala [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] OS timezone files support
Zdenek Kotala [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] OS timezone files support
Magnus Hagander wrote: Tom Lane wrote: Zdenek Kotala [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
