|
Home > Archive > PostgreSQL Hacks > October 2005 > Re: [BUGS] BUG #1993: Adding/subtracting negative time intervals
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: [BUGS] BUG #1993: Adding/subtracting negative time intervals
|
|
| Bruce Momjian 2005-10-27, 8:14 am |
|
[ bugs list removed, hackers added.]
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
>
> It's too late to mess with it for 8.1, but see my previous message
> proposing a set of TODO items for future work.
Yes, it is late, but I am worried about adding an interface change that
we will later revert in 8.2. In 8.0.X I see the query returning the '25
hour' answer:
SELECT
('2005-10-29 13:22:00-04'::timestamptz +
('2005-10-30 13:22:00-05'::timestamptz -
'2005-10-29 13:22:00-04'::timestamptz)) at time zone 'EST';
timezone
---------------------
2005-10-30 13:22:00
(1 row)
In current CVS the top query returns '14:22:00'. Do we change this for
8.1, then change it back in 8.2? That seems bad to me.
Actually, 8.0.X returns '1 day, 1 hour' for the subtraction, which we
treat in 8.0.X as '25 hours':
SELECT
('2005-10-30 13:22:00-05'::timestamptz -
'2005-10-29 13:22:00-04'::timestamptz);
?column?
----------------
1 day 01:00:00
(1 row)
In 8.0.X, because we didn't have a 'days' field, we could treat '1 day 1
hour' as always '25 hours', and could display the results as days/hours.
If we remove interval_justify_hou
rs(), then we are always going to
display timestamp subtraction in hours (not days), e.g. '6422 hours'
(yea, ugly) unless they manually call interval_justify_hou
rs().
Keep in mind that the addition of the interval_justify_hou
rs() did
generate some regression test changes, so removing
interval_justify_hou
rs() might just take the results back to what we had
in 8.0. My point is that regression changes caused by its removal might
not be a good guide to determining compatibility with 8.0.X.
I guess my point is that we are changing 8.0.X behavior so we better be
sure it is now the way we want it to remain.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
| |
| Tom Lane 2005-10-27, 8:14 am |
| Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Keep in mind that the addition of the interval_justify_hou
rs() did
> generate some regression test changes, so removing
> interval_justify_hou
rs() might just take the results back to what we had
> in 8.0.
Not hardly. I tried already. The existing timestamp_mi behavior is
probably as close to 8.0 as we can get given the change in underlying
representation.
> I guess my point is that we are changing 8.0.X behavior so we better be
> sure it is now the way we want it to remain.
[ shrug... ] We've changed datetime behavior in every past release,
we're changing it for 8.1, we'll probably change it some more for 8.2,
and again after that. All the datetime code is a work in progress.
Get used to it.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
| |
| Bruce Momjian 2005-10-27, 8:14 am |
| Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
>
> Not hardly. I tried already. The existing timestamp_mi behavior is
> probably as close to 8.0 as we can get given the change in underlying
> representation.
You mean the '6432 hours' is a worse change, OK.
>
> [ shrug... ] We've changed datetime behavior in every past release,
> we're changing it for 8.1, we'll probably change it some more for 8.2,
> and again after that. All the datetime code is a work in progress.
> Get used to it.
OK, as long as we are sure we are not going to change it back to 8.0
behavior.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
| |
| Tom Lane 2005-10-27, 8:14 am |
| Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
[color=darkred]
> You mean the '6432 hours' is a worse change, OK.
Well, it's sure not a small change, and we're still undecided whether
that's what we want in the long run.
Also, we'd have to deal with some of the other TODO items I mentioned
before we could make it work at all. There's at least one regression
test that computes an interval larger than 2^31 hours (how do you think
I found out about that problem ;-))
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
|
|
|
|
|