On Wed, 2009-03-25 at 19:31 -0400, Tom Lane wrote:
> * I'd also like to come to some agreement about getting rid of the
> fail-on-NULL-scankey problem in newScanKey(). As I noted in the
> comment there, we could make that work cleanly if we are willing to
> assume that all GIN-indexable operators are strict. We already assume
> the same for hash and btree operators, so it doesn't seem like a big
> problem to do this, but I wonder if there are any objections.
"IS NULL" is indexable in a btree and non-strict, so there is at least
some precedent.
Also, if extractQuery is non-strict, shouldn't we call it and see if it
returns some useful keys? If so, I don't see a reason to assume that
nothing matches.
If the opclass author wants a search against NULL to mean "matches
nothing", they can just make extractQuery non-strict and return -1.
However, if extractQuery is strict or returns NULL, I'm fine with either
an error or assuming "nothing matches". I don't see a functionality
difference either way, so we should just document whatever seems to make
the most sense.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
