Tom Lane wrote:
Josh Berkus josh@agliodbs.com writes:
Zdenec,
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.
If we're adding it as a
Granted, but a configure switch would allow users who want to use OS TZ
file in conjunction with a compiled from source installation. Many
users of OSes with package managers such as Debian or RedHat may, for
whatever reason, want to use a source tarball to install and also use
the OS TZ list.
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
Martijn van Oosterhout wrote:
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.
I don't think you can reasonably
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
Andrew Dunstan wrote:
Martijn van Oosterhout wrote:
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.
I don't think
Andrew Dunstan wrote:
Martijn van Oosterhout wrote:
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.
I don't think you
Martijn van Oosterhout kleptog@svana.org writes:
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: ...
One other point is that symlinking to system timezone
Andrew Dunstan [EMAIL PROTECTED] writes:
But I take Tom's point about most users not knowing if their TZ database
is usable or not. Maybe we need a tool (maybe on pgfoundry) that will do
some analysis to find out, if such a thing is possible.
It's not really *that* hard: diff between our
It appears that we didn't do enough research in regards to the recent
DST switch. We poorly assumed that having our machine's timezone files
up to date would be sufficient not knowing that our version of
postgres relied on its own timezone files.
The question is... can we symlink the
Michael,
I'm also curious about the rationale to maintain a separate timezone
data files for machines that supply them.
It's because we found that we couldn't ensure consistency between operating
systems while relying on OS files.
--
Josh Berkus
PostgreSQL @ Sun
San Francisco
Tom,
You can try the symlink game if you want, but it'll be on your own head
whether it works or not. (For the record, I am hoping to do exactly
that in future releases for Red Hat ... but in that context I know what
the system's timezone code is. I'm less sure that I know what Apple
is
You can try the symlink game if you want, but it'll be on your own head
whether it works or not. (For the record, I am hoping to do exactly
that in future releases for Red Hat ... but in that context I know what
the system's timezone code is. I'm less sure that I know what Apple
is using.)
Michael,
Currently Apple's format appears to work fine with postgresql. And
given the responses and to make a quick job of it I will be copying
Apple's files only on the machines affected instead of symlinking
until we can coordinate a new version update. It seems that we are
only being
Tom Lane wrote:
Josh Berkus josh@agliodbs.com writes:
Michael,
I'm also curious about the rationale to maintain a separate timezone
data files for machines that supply them.
It's because we found that we couldn't ensure consistency between operating
systems while relying on OS files.
Zdenec,
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.
If we're adding it as a configure-time variable, there's no reason to have
a GUC.
Josh Berkus wrote:
Tom,
You can try the symlink game if you want, but it'll be on your own head
whether it works or not. (For the record, I am hoping to do exactly
that in future releases for Red Hat ... but in that context I know what
the system's timezone code is. I'm less sure that I
Josh Berkus josh@agliodbs.com writes:
Zdenec,
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.
If we're adding it as a configure-time
18 matches
Mail list logo
