Re: Bug#311533: Invalid timestamp returned because of timezone - Mailing list pgsql-bugs

From Andrew - Supernews
Subject Re: Bug#311533: Invalid timestamp returned because of timezone
Date
Msg-id slrndak8j5.2799.andrew+nonews@trinity.supernews.net
Whole thread Raw
In response to Re: Bug#311533: Invalid timestamp returned because of timezone  (Martin Pitt <martin@piware.de>)
Responses Re: Bug#311533: Invalid timestamp returned because of timezone
List pgsql-bugs
On 2005-06-10, Martin Pitt <martin@piware.de> wrote:
>> As per conversation in #postgresql in freenode, it has been found that
>> this seems to manifest on pgsql compiled using integer-datetime;
>> float-datetime version does not have this problem.
>
> I just tried to do the proposed change, however, it is not possible to
> start the new postmaster on an already existing cluster. You had to
> dump all clusters with the old postmaster, install the new one and
> recreate the clusters, which is a hell of an upgrade (so it's
> definitively nothing for Sarge, even less for sarge-proposed updates).
> So I can't apply that change for now.

Out of curiosity, why was it using the integer-datetimes option at all?
It's not the default in the distributed source, and it's had a series of
bugs found in it, this being merely the latest.

> The cleanest one would obviously be to fix integer timestamps, or if
> that is not possible, at least support selecting integer or float time
> stamps at runtime (maybe as a postmaster option). Can this be done in
> any way?

Since changing the option affects how every single timestamp value in the
database is stored, it's hard to see how it could be made switchable at
runtime.

--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services

pgsql-bugs by date:

Previous
From: "James Doherty"
Date:
Subject: BUG #1715: dbmirror replaces nextval, setval functions
Next
From: Martin Pitt
Date:
Subject: Re: Bug#311533: Invalid timestamp returned because of timezone