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
Martijn van Oosterhout 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 info will not
cau
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
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 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 ave
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 describ
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 compi
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.
Tom Lane wrote:
Josh Berkus 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 variable,
Josh Berkus 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 variable, ther
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 kn
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
Tom Lane wrote:
Josh Berkus 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.
Partly that, and partl
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
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.)
Tha
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
> i
Josh Berkus 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.
Partly that, and partly that we
On Tue, Mar 13, 2007 at 12:20:25PM -0400, Michael Ledford wrote:
> 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
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
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 share/postgr
20 matches
Mail list logo
