Martijn van Oosterhout wrote:
> On Wed, Mar 14, 2007 at 01:13:58PM +0100, Zdenek Kotala wrote:
>> 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)
>
> What is the actual problem being solved here? That people expected the
> timezone changes to be picked up automatically? think if you weigh it
> up, that problem is less significant than:
People expect consistent timezone setting for all application on one
machine.
> 1. You do a minor system upgrade and now postgres crashes because the
> file format changed or the files moved.
When you perform minor system upgrade which will delivery new TZ file
format, than new version of libc must be delivery anyway and you
probably must recompile postgres on upgraded system -> you can check if TZ files works fine and if not you can
compileit with build in.
If file is moved, postgres raises error. But I don't see problem there.
If you compare changes between 8.1.5 and 8.1.6, you can see a lot of
removed files.
> 2. You run a replication system and get different results on different
> machine.
However on another point of view, You very often have application and
postgres on one machine. And if you have different tz files for
application and for postgres, the result should be really strange. This
case is most common than replication issue.
>
> I think that from a data integrity point of view the current system is
> the best. At the very least what you propose is a modularity violation:
> Postgres depending on undocumented private data of another system
> component.
Yes, it is true, dependency on private data is not good. But It is
"smaller evil", than have more different timezone on one system.
Zdenek