[EMAIL PROTECTED] writes:
> the ?# (geometric intersection) operator for paths iterates over point
> pairs in each path testing for intersection. however, it ignores the
> last->first point pair for closed paths.
Looks like a bug to me too; and path_distance, path_length, dist_ppath
also fail to
"Mike Quinn" <[EMAIL PROTECTED]> writes:
[ query behaves okay as
WHERE Crops.change_e > '10/1/2001'
but not as
WHERE '10/1/2001' < Crops.change_e
]
Ah-hah, I see it. The critical factor is that you have some +infinity
values in that timestamp column, so that the column data ra
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
> I've noticed general buggyness with ecpg on
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Shouldn't infinity be treated similar to NULL.
Nope. It has a definite position in the sort order.
regards, tom lane
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaste
> The reason I didn't see it here is that on my platform, the infinity
> timestamp values aren't represented as real IEEE infinities, and so the
> result isn't NAN.
>
> Seems like we could fix this either by forbidding use of real infinity
> for timestamp and float8 values ... probably not workab
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Shouldn't infinity be treated similar to NULL.
>
> Nope. It has a definite position in the sort order.
I was thinking about the optimizer's histogram, not the index ordering.
Anyway, seems you got it fixed already.
--
Bruce Momjian
