Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > Thomas Munro writes:
> > > Is the plan to remove support for floating point timestamps at some
> > > stage? If so, what is that waiting on, and would it provide
> > > sufficient warning if (say) 9.6 were documented as the last majo
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Thomas Munro writes:
> > Is the plan to remove support for floating point timestamps at some
> > stage? If so, what is that waiting on, and would it provide
> > sufficient warning if (say) 9.6 were documented as the last major
> > release to support that b
Thomas Munro writes:
> Is the plan to remove support for floating point timestamps at some
> stage? If so, what is that waiting on, and would it provide
> sufficient warning if (say) 9.6 were documented as the last major
> release to support that build option?
AFAIK there is no particular plan t
Hi,
Is the plan to remove support for floating point timestamps at some
stage? If so, what is that waiting on, and would it provide
sufficient warning if (say) 9.6 were documented as the last major
release to support that build option?
Thanks!
--
Thomas Munro
http://www.enterprisedb.com
--
On Mon, Oct 25, 2010 at 4:35 PM, James Cloos wrote:
>> "TL" == Tom Lane writes:
>
> JC> That said, the possiblity of hex i/o format for the float datatypes
> JC> would be welcome.
>
> TL> It's unportable, for two different reasons:
>
> TL> 2. The printf specifiers you want us to rely on are n
> "TL" == Tom Lane writes:
JC> That said, the possiblity of hex i/o format for the float datatypes
JC> would be welcome.
TL> It's unportable, for two different reasons:
TL> 2. The printf specifiers you want us to rely on are not standard.
They are in C99.
TL> 1. pg_dump output would becom
James Cloos writes:
> That said, the possiblity of hex i/o format for the float datatypes
> would be welcome.
It's unportable, for two different reasons:
1. pg_dump output would become platform-specific. This is highly
undesirable.
2. The printf specifiers you want us to rely on are not standa
> "JD" == Jeff Davis writes:
JD> 2. Fix the input/output functions in a special mode for dump/reload,
JD> to make them true inverses.
JC> That can be done by supporting the %A printf(3)/scanf(3) format.
JD> I don't happen to see a %A format in the man page, but I doubt the
JD> output would
On Mon, 2010-10-25 at 13:54 -0400, James Cloos wrote:
> > "JD" == Jeff Davis writes:
>
> JD> 2. Fix the input/output functions in a special mode for dump/reload,
> JD>to make them true inverses.
>
> That can be done by supporting the %A printf(3)/scanf(3) format.
I don't happen to see a
> "JD" == Jeff Davis writes:
JD> 2. Fix the input/output functions in a special mode for dump/reload,
JD>to make them true inverses.
That can be done by supporting the %A printf(3)/scanf(3) format.
-JimC
--
James Cloos OpenPGP: 1024D/ED7DAEA6
--
Sent via pgsql-hackers mailin
On Thu, Oct 21, 2010 at 10:24 PM, Tom Lane wrote:
> Bruce Momjian writes:
>> Greg Stark wrote:
>>> Did we have a solution for the problem that understanding which
>>> columns are timestamps requires having a tuple descriptor and parsing
>>> the every tuple? That seems like it would a) be slow and
On Thu, Oct 21, 2010 at 7:24 PM, Tom Lane wrote:
> Would we be willing to make such assumptions to
> support in-place upgrade of timestamps?
>
If something like that is true (I'm not sure it is) then we could
consider doing the equivalent of what we were talking about doing for
changes that requ
Bruce Momjian writes:
> Greg Stark wrote:
>> Did we have a solution for the problem that understanding which
>> columns are timestamps requires having a tuple descriptor and parsing
>> the every tuple? That seems like it would a) be slow and b) require a
>> lot of high level code in the middle of
Greg Stark wrote:
> On Thu, Oct 21, 2010 at 4:49 PM, Bruce Momjian wrote:
> > One thing we have talked about is converting the page on read-in from
> > the backend. ?Since the timestamps are the same size as float or
> > integer, that might be possible.
>
> Did we have a solution for the problem
On Thu, Oct 21, 2010 at 4:49 PM, Bruce Momjian wrote:
> One thing we have talked about is converting the page on read-in from
> the backend. Since the timestamps are the same size as float or
> integer, that might be possible.
Did we have a solution for the problem that understanding which
colum
Robert Haas wrote:
> On Mon, Oct 18, 2010 at 2:29 PM, Jeff Davis wrote:
> > A reasonable conversion path might be to offer integer timestamps using
> > a different type name (e.g. inttimestamp) that always means integer
> > timestamps. Then, they could convert using ALTER TABLE, then do an
> > in-
On Mon, 2010-10-18 at 14:49 -0400, Tom Lane wrote:
> whereas an int-timestamp build sees these inputs as all the same.
> Thus, to get into trouble you'd need to have a unique index on data that
> conflicts at the microsecond scale but not at the tenth-of-a-microsecond
> scale. This seems implausib
On Mon, Oct 18, 2010 at 2:29 PM, Jeff Davis wrote:
> A reasonable conversion path might be to offer integer timestamps using
> a different type name (e.g. inttimestamp) that always means integer
> timestamps. Then, they could convert using ALTER TABLE, then do an
> in-place upgrade. We could even
Robert Haas writes:
> A more interesting question is whether and how we can ease the
> migration path from float timestamps to integer timestamps. Even
> without range types, if someone does have a UNIQUE index on a
> timestamp column, could they get an error if they dump from a
> float-timestamp
On Mon, 2010-10-18 at 14:06 -0400, Robert Haas wrote:
> Right. I think your argument that we should "do nothing" upthread is
> exactly right.
OK.
> A more interesting question is whether and how we can ease the
> migration path from float timestamps to integer timestamps. Even
> without range
On Mon, Oct 18, 2010 at 1:12 PM, Tom Lane wrote:
> IOW I don't think the range argument holds much water for keeping float
> timestamps alive. The on-disk-compatibility argument does, though.
Right. I think your argument that we should "do nothing" upthread is
exactly right. Deprecating float
Andrew Dunstan writes:
> On 10/17/2010 04:40 PM, Tom Lane wrote:
>> ... That's assuming that we think there are
>> no users who are depending on float timestamps for functionality (they
>> have a wider range than int timestamps don't they?).
> Yes, they do.
> Maybe we need to look at providing a
On Sun, 2010-10-17 at 15:52 -0700, Greg Stark wrote:
> On Sun, Oct 17, 2010 at 12:03 PM, Joshua D. Drake
> wrote:
> > The only major distribution that I know of that ships the deprecated
> > configuration is RedHat/Fedora. I don't know when that will change.
> >
>
> If only we knew someone in Re
On Sun, Oct 17, 2010 at 12:03 PM, Joshua D. Drake
wrote:
> The only major distribution that I know of that ships the deprecated
> configuration is RedHat/Fedora. I don't know when that will change.
>
If only we knew someone in Redhat :)
iirc the issue was binary upgrades. So I suspect the answe
On Sun, 2010-10-17 at 16:27 -0400, Tom Lane wrote:
> "Joshua D. Drake" writes:
> > The only major distribution that I know of that ships the deprecated
> > configuration is RedHat/Fedora. I don't know when that will change.
>
> Red Hat switched to integer datetimes as of 8.4 ... just like upstrea
On 10/17/2010 04:40 PM, Tom Lane wrote:
At the earliest, we could consider dropping them when we drop support
for in-place upgrade from 8.3 --- not only direct upgrade, but through
multiple pg_upgrade steps. That's assuming that we think there are
no users who are depending on float timestamps
Jeff Davis writes:
> On Sun, 2010-10-17 at 16:17 -0400, Tom Lane wrote:
>> There is maybe some argument for removing the float timestamp code
>> altogether, but I think that that's probably premature. They were
>> still the default in 8.3, and we are still supporting in-place upgrade
>> from 8.3.
On Sun, 2010-10-17 at 16:17 -0400, Tom Lane wrote:
> I'm for that one. Anybody working with fractional float timestamps
> should already understand that they aren't exact. I can't see the value
> of expending any great amount of effort on this.
OK.
> There is maybe some argument for removing th
"Joshua D. Drake" writes:
> The only major distribution that I know of that ships the deprecated
> configuration is RedHat/Fedora. I don't know when that will change.
Red Hat switched to integer datetimes as of 8.4 ... just like upstream.
Please don't imagine that you can complain that Red Hat is
Jeff Davis writes:
> What should be done? I see a few options:
> 1. Do nothing. Floating-point timestamps aren't the default, and the bug
> reports are likely to be few and far between (but those that encounter
> the bug are likely to be very frustrated).
I'm for that one. Anybody working with
On Sun, 2010-10-17 at 10:00 -0700, David E. Wheeler wrote:
> On Oct 17, 2010, at 9:56 AM, Jeff Davis wrote:
>
> > 3. Somehow deprecate floating point timestamps or make them unusable in
> > conjunction with Range Types. I'm not sure if there is demand to keep
> > them alive or not.
>
This seems
On Oct 17, 2010, at 9:56 AM, Jeff Davis wrote:
> 3. Somehow deprecate floating point timestamps or make them unusable in
> conjunction with Range Types. I'm not sure if there is demand to keep
> them alive or not.
+1
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
I'm working on the design for Range Types for 9.1:
http://wiki.postgresql.org/wiki/RangeTypes
But I think that floating-point timestamps may pose a problem. In this
thread:
http://archives.postgresql.org/pgsql-bugs/2010-08/msg00378.php
I pointed out that floating-point timestamps can become
33 matches
Mail list logo
