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 compile it 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
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
