Issues with generate_series using integer boundaries

On 1 February 2011 00:15, Thom Brown <thom@linux.com> wrote:

Hi,

I've noticed that if I try to use generate_series to include the upper
boundary of int4, it never returns:

SELECT x FROM generate_series(2147483643::int4, 2147483647::int4) AS a(x);

But the same query with int8 returns instantly:

SELECT x FROM generate_series(2147483643::int8, 2147483647::int8) AS a(x);

However, the int8 version of generate_series has the same problem.
This never returns:

SELECT x FROM generate_series(9223372036854775803::int8,
9223372036854775807::int8) AS a(x);

Another issue happens when using the lower boundaries:

postgres=# SELECT x FROM generate_series(-2147483648::int4,
-2147483644::int4) AS a(x);
ERROR:  integer out of range
postgres=# SELECT x FROM generate_series(-9223372036854775808::int8,
-9223372036854775804::int8) AS a(x);
ERROR:  bigint out of range

I've recreated this on 9.0.1 and 9.1devel on a 64-bit platform.

Bug?

Actually, those lower bound errors aren't related to generate_series,
but I'd still like to know why -2147483648::int4 is out of range.

--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935

Thom Brown <thom@linux.com> writes:

Actually, those lower bound errors aren't related to generate_series,
but I'd still like to know why -2147483648::int4 is out of range.

:: binds tighter than - (and everything else too). Write
(-2147483648)::int4 instead.

regards, tom lane

On 1 February 2011 00:36, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Thom Brown <thom@linux.com> writes:

Actually, those lower bound errors aren't related to generate_series,
but I'd still like to know why -2147483648::int4 is out of range.

:: binds tighter than - (and everything else too).  Write
(-2147483648)::int4 instead.

D'oh. You explained this to me before. This time I'll endeavour to
remember it. At least that explains the problem I created for myself
with lower boundaries.

--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935

On 1 February 2011 00:41, Thom Brown <thom@linux.com> wrote:

On 1 February 2011 00:36, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Thom Brown <thom@linux.com> writes:

Actually, those lower bound errors aren't related to generate_series,
but I'd still like to know why -2147483648::int4 is out of range.

:: binds tighter than - (and everything else too).  Write
(-2147483648)::int4 instead.

D'oh.  You explained this to me before.  This time I'll endeavour to
remember it.  At least that explains the problem I created for myself
with lower boundaries.

Okay, so lower boundaries are still affected in the same way as upper
boundaries after all, at least when using a reverse series:

SELECT x FROM generate_series((-2147483644)::int4,
(-2147483648)::int4, -1) AS a(x);

--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935

Thom Brown <thom@linux.com> writes:

I've noticed that if I try to use generate_series to include the upper
boundary of int4, it never returns:

I'll bet it's testing "currval > bound" without considering the
possibility that incrementing currval caused an overflow wraparound.
We fixed a similar problem years ago in plpgsql FOR-loops...

regards, tom lane

On 1 February 2011 01:05, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Thom Brown <thom@linux.com> writes:

I've noticed that if I try to use generate_series to include the upper
boundary of int4, it never returns:

I'll bet it's testing "currval > bound" without considering the
possibility that incrementing currval caused an overflow wraparound.
We fixed a similar problem years ago in plpgsql FOR-loops...

And here's another case:

SELECT x FROM generate_series(2147483643, 2147483644,5) AS a(x);

A step of 1 would work fine, but forcing it to exceed the boundary in
this way means it never returns.

--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935

On 1 February 2011 01:05, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Thom Brown <thom@linux.com> writes:

I've noticed that if I try to use generate_series to include the upper
boundary of int4, it never returns:

I'll bet it's testing "currval > bound" without considering the
possibility that incrementing currval caused an overflow wraparound.
We fixed a similar problem years ago in plpgsql FOR-loops...

Yes, you're right. Internally, the current value is checked against
the finish. If it hasn't yet passed it, the current value is
increased by the step. When it reaches the upper bound, since it
hasn't yet exceeded the finish, it proceeds to increment it again,
resulting in the iterator wrapping past the upper bound to become the
lower bound. This then keeps it looping from the lower bound upward,
so the current value stays well below the end.

--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935

On 1 Feb 2011, at 21:26, Thom Brown wrote:

On 1 February 2011 01:05, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Thom Brown <thom@linux.com> writes:

I've noticed that if I try to use generate_series to include the upper
boundary of int4, it never returns:

I'll bet it's testing "currval > bound" without considering the
possibility that incrementing currval caused an overflow wraparound.
We fixed a similar problem years ago in plpgsql FOR-loops...

Yes, you're right. Internally, the current value is checked against
the finish. If it hasn't yet passed it, the current value is
increased by the step. When it reaches the upper bound, since it
hasn't yet exceeded the finish, it proceeds to increment it again,
resulting in the iterator wrapping past the upper bound to become the
lower bound. This then keeps it looping from the lower bound upward,
so the current value stays well below the end.

That could actually be used as a feature to create a repeating series. A bit more control would be useful though :P

Alban Hertroys

--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.

!DSPAM:737,4d487c1211731974314558!

On 1 February 2011 21:32, Alban Hertroys
<dalroi@solfertje.student.utwente.nl> wrote:

On 1 Feb 2011, at 21:26, Thom Brown wrote:

On 1 February 2011 01:05, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Thom Brown <thom@linux.com> writes:

I've noticed that if I try to use generate_series to include the upper
boundary of int4, it never returns:

I'll bet it's testing "currval > bound" without considering the
possibility that incrementing currval caused an overflow wraparound.
We fixed a similar problem years ago in plpgsql FOR-loops...

Yes, you're right.  Internally, the current value is checked against
the finish.  If it hasn't yet passed it, the current value is
increased by the step.  When it reaches the upper bound, since it
hasn't yet exceeded the finish, it proceeds to increment it again,
resulting in the iterator wrapping past the upper bound to become the
lower bound.  This then keeps it looping from the lower bound upward,
so the current value stays well below the end.

That could actually be used as a feature to create a repeating series. A bit more control would be useful though :P

I don't quite understand why the code works. As I see it, it always
returns a set with values 1 higher than the corresponding result. So
requesting 1 to 5 actually returns 2 to 6 internally, but somehow it
correctly shows 1 to 5 in the query output. If there were no such
discrepancy, the upper-bound/lower-bound problem wouldn't exist, so
not sure how those output values result in the correct query result
values.

--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935

On 1 February 2011 23:08, Thom Brown <thom@linux.com> wrote:

On 1 February 2011 21:32, Alban Hertroys
<dalroi@solfertje.student.utwente.nl> wrote:

On 1 Feb 2011, at 21:26, Thom Brown wrote:

On 1 February 2011 01:05, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Thom Brown <thom@linux.com> writes:

I've noticed that if I try to use generate_series to include the upper
boundary of int4, it never returns:

I'll bet it's testing "currval > bound" without considering the
possibility that incrementing currval caused an overflow wraparound.
We fixed a similar problem years ago in plpgsql FOR-loops...

Yes, you're right.  Internally, the current value is checked against
the finish.  If it hasn't yet passed it, the current value is
increased by the step.  When it reaches the upper bound, since it
hasn't yet exceeded the finish, it proceeds to increment it again,
resulting in the iterator wrapping past the upper bound to become the
lower bound.  This then keeps it looping from the lower bound upward,
so the current value stays well below the end.

That could actually be used as a feature to create a repeating series. A bit more control would be useful though :P

I don't quite understand why the code works.  As I see it, it always
returns a set with values 1 higher than the corresponding result.  So
requesting 1 to 5 actually returns 2 to 6 internally, but somehow it
correctly shows 1 to 5 in the query output.  If there were no such
discrepancy, the upper-bound/lower-bound problem wouldn't exist, so
not sure how those output values result in the correct query result
values.

Okay, I've attached a patch which fixes it. It allows ranges up to
upper and down to lower bounds as well as accounting for the
possibility for the step to cause misalignment of the iterating value
with the end value. The following now works which would usually get
stuck in a loop:

postgres=# SELECT x FROM generate_series(2147483643::int4,
2147483647::int4) AS a(x);
x
------------
2147483643
2147483644
2147483645
2147483646
2147483647
(5 rows)

postgres=# SELECT x FROM generate_series(2147483642::int4,
2147483647::int4, 2) AS a(x);
x
------------
2147483642
2147483644
2147483646
(3 rows)

postgres=# SELECT x FROM generate_series(2147483643::int4,
2147483647::int4, 6) AS a(x);
x
------------
2147483643
(1 row)

It's probably safe to assume the changes in the patch aren't up to
scratch and it's supplied for demonstration purposes only, so could
someone please use the same principals and code in the appropriate
changes?

Thanks

--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935

On 3 February 2011 11:31, Thom Brown <thom@linux.com> wrote:

On 1 February 2011 23:08, Thom Brown <thom@linux.com> wrote:

On 1 February 2011 21:32, Alban Hertroys
<dalroi@solfertje.student.utwente.nl> wrote:

On 1 Feb 2011, at 21:26, Thom Brown wrote:

On 1 February 2011 01:05, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Thom Brown <thom@linux.com> writes:

I've noticed that if I try to use generate_series to include the upper
boundary of int4, it never returns:

I'll bet it's testing "currval > bound" without considering the
possibility that incrementing currval caused an overflow wraparound.
We fixed a similar problem years ago in plpgsql FOR-loops...

Yes, you're right.  Internally, the current value is checked against
the finish.  If it hasn't yet passed it, the current value is
increased by the step.  When it reaches the upper bound, since it
hasn't yet exceeded the finish, it proceeds to increment it again,
resulting in the iterator wrapping past the upper bound to become the
lower bound.  This then keeps it looping from the lower bound upward,
so the current value stays well below the end.

That could actually be used as a feature to create a repeating series. A bit more control would be useful though :P

I don't quite understand why the code works.  As I see it, it always
returns a set with values 1 higher than the corresponding result.  So
requesting 1 to 5 actually returns 2 to 6 internally, but somehow it
correctly shows 1 to 5 in the query output.  If there were no such
discrepancy, the upper-bound/lower-bound problem wouldn't exist, so
not sure how those output values result in the correct query result
values.

Okay, I've attached a patch which fixes it.  It allows ranges up to
upper and down to lower bounds as well as accounting for the
possibility for the step to cause misalignment of the iterating value
with the end value.  The following now works which would usually get
stuck in a loop:

postgres=# SELECT x FROM generate_series(2147483643::int4,
2147483647::int4) AS a(x);
    x
------------
 2147483643
 2147483644
 2147483645
 2147483646
 2147483647
(5 rows)

postgres=# SELECT x FROM generate_series(2147483642::int4,
2147483647::int4, 2) AS a(x);
    x
------------
 2147483642
 2147483644
 2147483646
(3 rows)

postgres=# SELECT x FROM generate_series(2147483643::int4,
2147483647::int4, 6) AS a(x);
    x
------------
 2147483643
(1 row)

It's probably safe to assume the changes in the patch aren't up to
scratch and it's supplied for demonstration purposes only, so could
someone please use the same principals and code in the appropriate
changes?

Thanks

And I see I accidentally included a doc change in there. Removed and
reattached:

--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935

On 3 February 2011 11:34, Thom Brown <thom@linux.com> wrote:

On 3 February 2011 11:31, Thom Brown <thom@linux.com> wrote:

On 1 February 2011 23:08, Thom Brown <thom@linux.com> wrote:

On 1 February 2011 21:32, Alban Hertroys
<dalroi@solfertje.student.utwente.nl> wrote:

On 1 Feb 2011, at 21:26, Thom Brown wrote:

On 1 February 2011 01:05, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Thom Brown <thom@linux.com> writes:

I've noticed that if I try to use generate_series to include the upper
boundary of int4, it never returns:

I'll bet it's testing "currval > bound" without considering the
possibility that incrementing currval caused an overflow wraparound.
We fixed a similar problem years ago in plpgsql FOR-loops...

Yes, you're right.  Internally, the current value is checked against
the finish.  If it hasn't yet passed it, the current value is
increased by the step.  When it reaches the upper bound, since it
hasn't yet exceeded the finish, it proceeds to increment it again,
resulting in the iterator wrapping past the upper bound to become the
lower bound.  This then keeps it looping from the lower bound upward,
so the current value stays well below the end.

That could actually be used as a feature to create a repeating series. A bit more control would be useful though :P

I don't quite understand why the code works.  As I see it, it always
returns a set with values 1 higher than the corresponding result.  So
requesting 1 to 5 actually returns 2 to 6 internally, but somehow it
correctly shows 1 to 5 in the query output.  If there were no such
discrepancy, the upper-bound/lower-bound problem wouldn't exist, so
not sure how those output values result in the correct query result
values.

Okay, I've attached a patch which fixes it.  It allows ranges up to
upper and down to lower bounds as well as accounting for the
possibility for the step to cause misalignment of the iterating value
with the end value.  The following now works which would usually get
stuck in a loop:

postgres=# SELECT x FROM generate_series(2147483643::int4,
2147483647::int4) AS a(x);
    x
------------
 2147483643
 2147483644
 2147483645
 2147483646
 2147483647
(5 rows)

postgres=# SELECT x FROM generate_series(2147483642::int4,
2147483647::int4, 2) AS a(x);
    x
------------
 2147483642
 2147483644
 2147483646
(3 rows)

postgres=# SELECT x FROM generate_series(2147483643::int4,
2147483647::int4, 6) AS a(x);
    x
------------
 2147483643
(1 row)

It's probably safe to assume the changes in the patch aren't up to
scratch and it's supplied for demonstration purposes only, so could
someone please use the same principals and code in the appropriate
changes?

Thanks

And I see I accidentally included a doc change in there.  Removed and
reattached:

Actually, further testing indicates this causes other problems:

postgres=# SELECT x FROM generate_series(1, 9,-1) AS a(x);
x
---
1
(1 row)

Should return no rows.

postgres=# SELECT x FROM generate_series(1, 9,3) AS a(x);
x
----
1
4
7
10
(4 rows)

Should return 3 rows.

--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935

On 3 February 2011 13:32, Thom Brown <thom@linux.com> wrote:

Actually, further testing indicates this causes other problems:

postgres=# SELECT x FROM generate_series(1, 9,-1) AS a(x);
 x
---
 1
(1 row)

Should return no rows.

postgres=# SELECT x FROM generate_series(1, 9,3) AS a(x);
 x
----
 1
 4
 7
 10
(4 rows)

Should return 3 rows.

Still messy code, but the attached patch does the job now:

postgres=# SELECT x FROM
generate_series(2147483643::int4,2147483647::int4) AS a(x);
x
------------
2147483643
2147483644
2147483645
2147483646
2147483647
(5 rows)

postgres=# SELECT x FROM
generate_series(2147483642::int4,2147483647::int4, 2) AS a(x);
x
------------
2147483642
2147483644
2147483646
(3 rows)

postgres=# SELECT x FROM
generate_series(2147483643::int4,2147483647::int4, 6) AS a(x);
x
------------
2147483643
(1 row)

postgres=# SELECT x FROM generate_series((-2147483643)::int4,
(-2147483648)::int4, -1) AS a(x);
x
-------------
-2147483643
-2147483644
-2147483645
-2147483646
-2147483647
-2147483648
(6 rows)

postgres=# SELECT x FROM generate_series(1, 9,-1) AS a(x);
x
---
(0 rows)

postgres=# SELECT x FROM generate_series(1, 9,3) AS a(x);
x
---
1
4
7
(3 rows)

--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935

The proposed generate_series(1,9,-1) behavior seems unusual. I think it
should throw a warning if the step direction and the start-end directions do
not match. Alternatively, the series generated could go from 9 -> 1 instead
of returning an empty series (basically the first two arguments are simply
bounds and the step sign determines which is upper and which is lower). The
result where the set contains the sole member { 1 } makes sense to me in
that you wanted to start with 1 and then increment by -1 until you are
either less-than 1 or greater-than 9; which is the same thing you are doing
when you have a positive step value and always treat the first argument as
the initial value. With that behavior you are ALWAYS returning the first
argument, then stepping, then returning any other argument that still fall
within the range. If you do not return the first argument you are
implicitly starting with zero (0) and incrementing and then seeing whether
the first step falls inside the specified range.

David J

-----Original Message-----
From: pgsql-general-owner@postgresql.org
[mailto:pgsql-general-owner@postgresql.org] On Behalf Of Thom Brown
Sent: Thursday, February 03, 2011 8:58 AM
To: Alban Hertroys
Cc: Tom Lane; PGSQL Mailing List
Subject: Re: [GENERAL] Issues with generate_series using integer boundaries

On 3 February 2011 13:32, Thom Brown <thom@linux.com> wrote:

Actually, further testing indicates this causes other problems:

postgres=# SELECT x FROM generate_series(1, 9,-1) AS a(x);
 x
---
 1
(1 row)

Should return no rows.

postgres=# SELECT x FROM generate_series(1, 9,3) AS a(x);
 x
----
 1
 4
 7
 10
(4 rows)

Should return 3 rows.

Still messy code, but the attached patch does the job now:

postgres=# SELECT x FROM
generate_series(2147483643::int4,2147483647::int4) AS a(x);
x
------------
2147483643
2147483644
2147483645
2147483646
2147483647
(5 rows)

postgres=# SELECT x FROM
generate_series(2147483642::int4,2147483647::int4, 2) AS a(x);
x
------------
2147483642
2147483644
2147483646
(3 rows)

postgres=# SELECT x FROM
generate_series(2147483643::int4,2147483647::int4, 6) AS a(x);
x
------------
2147483643
(1 row)

postgres=# SELECT x FROM generate_series((-2147483643)::int4,
(-2147483648)::int4, -1) AS a(x);
x
-------------
-2147483643
-2147483644
-2147483645
-2147483646
-2147483647
-2147483648
(6 rows)

postgres=# SELECT x FROM generate_series(1, 9,-1) AS a(x); x
---
(0 rows)

postgres=# SELECT x FROM generate_series(1, 9,3) AS a(x); x
---
1
4
7
(3 rows)

--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935

On 3 February 2011 14:37, David Johnston <polobo@yahoo.com> wrote:

The proposed generate_series(1,9,-1) behavior seems unusual.

I haven't proposed this behaviour as it already occurs. I just
include it for testing to ensure no other part of generate series is
affected by such changes. Whether or not that is desired behaviour is
separate as I only wish to fix the bug.

--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935

On 3 February 2011 13:58, Thom Brown <thom@linux.com> wrote:

On 3 February 2011 13:32, Thom Brown <thom@linux.com> wrote:

Actually, further testing indicates this causes other problems:

postgres=# SELECT x FROM generate_series(1, 9,-1) AS a(x);
 x
---
 1
(1 row)

Should return no rows.

postgres=# SELECT x FROM generate_series(1, 9,3) AS a(x);
 x
----
 1
 4
 7
 10
(4 rows)

Should return 3 rows.

Still messy code, but the attached patch does the job now:

postgres=# SELECT x FROM
generate_series(2147483643::int4,2147483647::int4) AS a(x);
    x
------------
 2147483643
 2147483644
 2147483645
 2147483646
 2147483647
(5 rows)

postgres=# SELECT x FROM
generate_series(2147483642::int4,2147483647::int4, 2) AS a(x);
    x
------------
 2147483642
 2147483644
 2147483646
(3 rows)

postgres=# SELECT x FROM
generate_series(2147483643::int4,2147483647::int4, 6) AS a(x);
    x
------------
 2147483643
(1 row)

postgres=# SELECT x FROM generate_series((-2147483643)::int4,
(-2147483648)::int4, -1) AS a(x);
     x
-------------
 -2147483643
 -2147483644
 -2147483645
 -2147483646
 -2147483647
 -2147483648
(6 rows)

postgres=# SELECT x FROM generate_series(1, 9,-1) AS a(x);
 x
---
(0 rows)

postgres=# SELECT x FROM generate_series(1, 9,3) AS a(x);
 x
---
 1
 4
 7
(3 rows)

Copying to -hackers.

The issue is that generate_series will not return if the series hits
either the upper or lower boundary during increment, or goes beyond
it. The attached patch fixes this behaviour, but should probably be
done a better way. The first 3 examples above will not return.

--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935

On Fri, Feb 4, 2011 at 21:32, Thom Brown <thom@linux.com> wrote:

The issue is that generate_series will not return if the series hits
either the upper or lower boundary during increment, or goes beyond
it.  The attached patch fixes this behaviour, but should probably be
done a better way.  The first 3 examples above will not return.

There are same bug in int8 and timestamp[tz] versions.
We also need fix for them.
=# SELECT x FROM generate_series(9223372036854775807::int8,
9223372036854775807::int8) AS a(x);
=# SELECT x FROM generate_series('infinity'::timestamp, 'infinity', '1
sec') AS a(x);
=# SELECT x FROM generate_series('infinity'::timestamptz, 'infinity',
'1 sec') AS a(x);

postgres=# SELECT x FROM generate_series(1, 9,-1) AS a(x);
postgres=# SELECT x FROM generate_series(1, 9,3) AS a(x);

They work as expected in 9.1dev.

--
Itagaki Takahiro

On 7 February 2011 09:04, Itagaki Takahiro <itagaki.takahiro@gmail.com> wrote:

On Fri, Feb 4, 2011 at 21:32, Thom Brown <thom@linux.com> wrote:

The issue is that generate_series will not return if the series hits
either the upper or lower boundary during increment, or goes beyond
it.  The attached patch fixes this behaviour, but should probably be
done a better way.  The first 3 examples above will not return.

There are same bug in int8 and timestamp[tz] versions.
We also need fix for them.
=# SELECT x FROM generate_series(9223372036854775807::int8,
9223372036854775807::int8) AS a(x);

Yes, of course, int8 functions are separate. I attach an updated
patch, although I still think there's a better way of doing this.

=# SELECT x FROM generate_series('infinity'::timestamp, 'infinity', '1
sec') AS a(x);
=# SELECT x FROM generate_series('infinity'::timestamptz, 'infinity',
'1 sec') AS a(x);

I'm not sure how this should be handled. Should there just be a check
for either kind of infinity and return an error if that's the case? I
didn't find anything wrong with using timestamp boundaries:

postgres=# SELECT x FROM generate_series('1 Jan 4713 BC
00:00:00'::timestamp, '1 Jan 4713 BC 00:00:05'::timestamp, '1 sec') AS
a(x);
x
------------------------
4713-01-01 00:00:00 BC
4713-01-01 00:00:01 BC
4713-01-01 00:00:02 BC
4713-01-01 00:00:03 BC
4713-01-01 00:00:04 BC
4713-01-01 00:00:05 BC
(6 rows)

Although whether this demonstrates a true timestamp boundary, I'm not sure.

postgres=# SELECT x FROM generate_series(1, 9,-1) AS a(x);
postgres=# SELECT x FROM generate_series(1, 9,3) AS a(x);

They work as expected in 9.1dev.

Those 2 were to demonstrate that the changes don't affect existing
functionality. My previous patch proposal (v2) caused these to return
unexpected output.

--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935

On Mon, Feb 7, 2011 at 20:38, Thom Brown <thom@linux.com> wrote:

Yes, of course, int8 functions are separate.  I attach an updated
patch, although I still think there's a better way of doing this.

Thanks. Please add the patch to the *current* commitfest
because it's a bugfix.
https://commitfest.postgresql.org/action/commitfest_view?id=9

I've not tested the patch yet, but if we could drop the following
line in the patch, the code could be much cleaner.
/* ensure first value in series should exist */

I'm not sure how this should be handled.  Should there just be a check
for either kind of infinity and return an error if that's the case?  I

Maybe so. It also works if we had infinity on timestamp overflow, but
I've not tested yet. Anyway, we need similar fix for timestamp versions.

--
Itagaki Takahiro