Alexander Korotkov <aekorot...@gmail.com> writes:
>> Thanks, Andrew! Good spot.
>> I didn't examine order by operators for work with NaNs.
>> I think this time problem is in GiST itself rather than in opclass. I'm
>> going to fix it in a separate patch.
> Attached patch fixes knn GiST behaviour with NaN. It makes RB-tree
> comparison function in GiST work like float8 btree opclass comparison
> function.
Hmm ... does that really work, or even do anything? I'd have thought
that if either input is a NAN, the initial test
if (sa->distances[i] != sb->distances[i])
would return false so we'd not enter the rest of it.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
