Patch applied. Thanks.
---
Michael Glaesemann wrote:
>
> On Sep 5, 2006, at 10:14 , Bruce Momjian wrote:
>
> > Bruce Momjian wrote:
> >> OK, updated patch. It will fix the >=24:00:00 case because it
> >> cascades
> >>
On Sep 5, 2006, at 10:14 , Bruce Momjian wrote:
Bruce Momjian wrote:
OK, updated patch. It will fix the >=24:00:00 case because it
cascades
up if the remainder number of seconds is greater or equal to one day.
One open item is that it still might show >24 hours if the seconds
computation co
Bruce Momjian wrote:
> OK, updated patch. It will fix the >=24:00:00 case because it cascades
> up if the remainder number of seconds is greater or equal to one day.
> One open item is that it still might show >24 hours if the seconds
> computation combined with the remaning seconds >24 hours. N
Bruce Momjian wrote:
> Michael Glaesemann wrote:
> >
> > On Sep 3, 2006, at 12:34 , Bruce Momjian wrote:
> >
> > > OK, I worked with Michael and I think this is the best we are going to
> > > do to fix this. It has one TSROUND call for Powerpc, and that is
> > > documented. Applied.
> >
> > As
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Is this non-datetime integer only or both? I cannot reproduce the
> > failure here.
>
> On HPPA with float datetimes with today's code, Michael's case works
> but it took me less than two minutes to find one that doesn't:
>
> regres
Michael Glaesemann wrote:
>
> On Sep 4, 2006, at 4:45 , Bruce Momjian wrote:
>
> > Another question. Is this result correct?
> >
> > test=> select '999 months 999 days'::interval / 100;
> > ?column?
> > -
> > 9 mons 38 days 40:33:36
> > (1 row
On Sep 4, 2006, at 4:45 , Bruce Momjian wrote:
Another question. Is this result correct?
test=> select '999 months 999 days'::interval / 100;
?column?
-
9 mons 38 days 40:33:36
(1 row)
Should that be:
9 mons 3
Michael Glaesemann wrote:
>
> On Sep 3, 2006, at 12:34 , Bruce Momjian wrote:
>
> > OK, I worked with Michael and I think this is the best we are going to
> > do to fix this. It has one TSROUND call for Powerpc, and that is
> > documented. Applied.
>
> As I was working up regression tests, I f
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Is this non-datetime integer only or both? I cannot reproduce the
> failure here.
On HPPA with float datetimes with today's code, Michael's case works
but it took me less than two minutes to find one that doesn't:
regression=# select interval '14 mon'
Is this non-datetime integer only or both? I cannot reproduce the
failure here.
---
Michael Glaesemann wrote:
>
> On Sep 3, 2006, at 12:34 , Bruce Momjian wrote:
>
> > OK, I worked with Michael and I think this is the bes
On Sep 3, 2006, at 12:34 , Bruce Momjian wrote:
OK, I worked with Michael and I think this is the best we are going to
do to fix this. It has one TSROUND call for Powerpc, and that is
documented. Applied.
As I was working up regression tests, I found a case that this patch
doesn't handle.
On Sep 1, 2006, at 20:39 , Michael Glaesemann wrote:
Here's a patch that appears to work. Gives the same output with and
without --enable-integer-datetimes. Answers look like they're correct.
I'm basically treating the components as three different intervals
(with the other two components
Michael Glaesemann <[EMAIL PROTECTED]> writes:
> Is it worth looking into the overflow and subtraction issues for 8.2?
> It seems to me they're bugs rather than features. Or are these 8.3
> since it's so late?
IMHO they're bugs not new features, and therefore perfectly fair game
to work on dur
Please ignore the patch I just sent. Much too quick with the send
button.
Michael Glaesemann
grzm seespotcode net
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your
Here's a patch that appears to work. Gives the same output with and
without --enable-integer-datetimes. Answers look like they're correct.
I'm basically treating the components as three different intervals
(with the other two components zero), rounding them each to usecs,
and adding them to
On Sep 1, 2006, at 11:03 , Bruce Momjian wrote:
I am unclear about this report. The patch was not meant to fix every
interval issue, but merely to improve multiplication and division
computations. Does it do that? I think the 23:60 is a time rounding
issue that isn't covered in this patch.
On Sep 1, 2006, at 11:31 , Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
I am unclear about this report. The patch was not meant to fix
every
interval issue, but merely to improve multiplication and division
computations. Does it do that?
According to Mi
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I am unclear about this report. The patch was not meant to fix every
> > interval issue, but merely to improve multiplication and division
> > computations. Does it do that?
>
> According to Michael's last report, your patch fails u
I am unclear about this report. The patch was not meant to fix every
interval issue, but merely to improve multiplication and division
computations. Does it do that? I think the 23:60 is a time rounding
issue that isn't covered in this patch. I am not against fixing it, but
does the submitted
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I am unclear about this report. The patch was not meant to fix every
> interval issue, but merely to improve multiplication and division
> computations. Does it do that?
According to Michael's last report, your patch fails under
--enable-integer-dateti
On Sep 1, 2006, at 5:05 , Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Well, the patch only multiplies by 30, so the interval would have to
span +5 million years to overflow. I don't see any reason to add
rounding until we get an actual query that needs it
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Well, the patch only multiplies by 30, so the interval would have to
> > span +5 million years to overflow. I don't see any reason to add
> > rounding until we get an actual query that needs it
>
> Have you tried your patch against t
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Well, the patch only multiplies by 30, so the interval would have to
> span +5 million years to overflow. I don't see any reason to add
> rounding until we get an actual query that needs it
Have you tried your patch against the various cases that have b
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > OK, here is a much nicer patch. The fix is to do no rounding, but to
> > find the number of days before applying the factor adjustment.
>
> You have forgotten the problem of the factor not being exactly
> representable (eg, things li
Bruce Momjian <[EMAIL PROTECTED]> writes:
> OK, here is a much nicer patch. The fix is to do no rounding, but to
> find the number of days before applying the factor adjustment.
You have forgotten the problem of the factor not being exactly
representable (eg, things like '10 days' * 0.1 not givin
Michael Glaesemann wrote:
>
> On Aug 30, 2006, at 12:50 , Bruce Momjian wrote:
>
> > Yea, I see that -122:23:60.00.
>
> After applying your patch, I believe that on my machine it's the
> contribution from the day component that is producing the 23:60.00.
> For example,
>
> select interval '
Michael Glaesemann wrote:
> > Yea, just an optimization, but I was worried that the computations
> > might
> > throw problems for certain numbers, so I figured I would only
> > trigger it
> > when necessary.
>
> Thanks for the explanation. Helps me know I might actually be
> learning this.
>
On Aug 30, 2006, at 12:50 , Bruce Momjian wrote:
Yea, I see that -122:23:60.00.
After applying your patch, I believe that on my machine it's the
contribution from the day component that is producing the 23:60.00.
For example,
select interval '-12 days' * 0.3;
?column?
---
On Aug 30, 2006, at 12:50 , Bruce Momjian wrote:
Here is a test program. What does it show for you?
The output for me is:
4.100
2.989
3.000
Here's what I get. Just to make sure I'm doing this right, I'm
including how I compile
Michael Glaesemann wrote:
> On Aug 30, 2006, at 7:12 , Bruce Momjian wrote:
>
> > Here are the results using my newest patch:
> >
> > test=> select interval '41 mon 12 days 360:00' / 10 as quotient_a
> > , interval '41 mon -12 days -360:00' / 10 as quotient_b
> > , interval '
On Aug 30, 2006, at 7:12 , Bruce Momjian wrote:
Here are the results using my newest patch:
test=> select interval '41 mon 12 days 360:00' / 10 as quotient_a
, interval '41 mon -12 days -360:00' / 10 as quotient_b
, interval '-41 mon 12 days 360:00' / 10 as quo
Michael Glaesemann wrote:
>
> On Aug 30, 2006, at 1:13 , Bruce Momjian wrote:
>
> > Uh, I came up with a cleaner one, I think. I didn't test
> > --enable-integer-datetimes yet.
>
> Cool. It's indeed much cleaner. Thanks, Bruce. I'm about to head to
> bed, but I'll look at it more closely tomo
On Aug 30, 2006, at 1:13 , Bruce Momjian wrote:
Uh, I came up with a cleaner one, I think. I didn't test
--enable-integer-datetimes yet.
Cool. It's indeed much cleaner. Thanks, Bruce. I'm about to head to
bed, but I'll look at it more closely tomorrow.
I also noticed that my regression t
Michael Glaesemann wrote:
>
> On Aug 29, 2006, at 15:38 , Michael Glaesemann wrote:
>
> > I think I've got it. I plan to update the regression tests this
> > evening, but I wanted to post what I believe is a solution.
>
> I've cleaned up the patch a bit in terms of whitespace, comments, and
I think I've got it. I plan to update the regression tests this
evening, but I wanted to post what I believe is a solution.
select '41 mon'::interval / 10;
?column?
---
4 mons 3 days
(1 row)
select '41 mon 360:00'::interval / 10 as "pos"
, '-41 mon -360:00'::interval / 10 as
On Aug 26, 2006, at 11:40 , Bruce Momjian wrote:
I used your ideas to make a patch to fix your example:
test=> select '41 months'::interval / 10;
?column?
---
4 mons 3 days
(1 row)
and
test=> select '41 months'::interval * 0.
I used your ideas to make a patch to fix your example:
test=> select '41 months'::interval / 10;
?column?
---
4 mons 3 days
(1 row)
and
test=> select '41 months'::interval * 0.3;
?column?
---
37 matches
Mail list logo
