Hackers,

Following is a patch to force the path type not to accept a path with
zero points. This appears to be illegal in the parser, but possible
when sending a well formed packed in binary with zero points. The old
behavior was this:

ERROR: floating-point exception
DETAIL: An invalid floating-point operation was signaled. This probably
means an out-of-range result or an invalid operation, such as division
by zero.

now it should properly display the points out of range error

merlin
eSilo

Index: src/backend/utils/adt/geo_ops.c
================================================== =================
RCS file: /projects/cvsroot/pgsql/src/backend/utils/adt/geo_ops.c,v
retrieving revision 1.97
diff -r1.97 geo_ops.c
1459c1459
< if (npts < 0 || npts >= (int32) ((INT_MAX - offsetof(PATH, p[0]))
/ sizeof(Point)))
---
> if (npts <= 0 || npts >= (int32) ((INT_MAX - offsetof(PATH, p[0])) / sizeof(Point)))

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

"Merlin Moncure" <mmoncure@gmail.com> writes:
> Following is a patch to force the path type not to accept a path with
> zero points. This appears to be illegal in the parser, but possible
> when sending a well formed packed in binary with zero points.

Hmm, looks like poly_recv has the same mistake.

Ideally I think it'd be a good idea if these types did allow zero
elements, but that would clearly be a feature extension more than a bug
fix, since the implications aren't entirely obvious. I concur with
disallowing the case for existing branches. Will go apply.

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