Oleg Bartunov <[EMAIL PROTECTED]> writes:
> we noticed you changed gist.c to handle NULLS. It seems there is
> problem with your changes.
I would like to see GIST upgraded to handle nulls, but at the moment
it's not null-safe. Try a few null entries, watch it core dump, if you
don't have that patch in place. (At least it does with the contrib/cube
opclass, didn't bother with any additional experiments.)
At the very least you'd need to replace all the uses of
DirectFunctionCallN to invoke the opclass support routines
with code that is capable of detecting and signaling nulls.
That would allow non-null-safe opclass routines to be protected
by marking them "strict".
But that's a micro-issue. The macro-issue is what you intend to
do with NULLs in the first place. I understand what btree does
with them, but what's the corresponding concept for GIST?
> I remind we have choosen to leave NULLs because vacuum complained about
> different number of tuples in heap and index and all our opclasses work
> correctly with NULLs. Did you change vacuum code so it will not complain ?
Yes.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
