Re: handling NULLS in GiST

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>
Cc: Teodor Sigaev <teodor(at)stack(dot)net>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: handling NULLS in GiST
Date: 2001-07-16 14:51:10
Message-ID: 7520.995295070@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Oleg Bartunov <oleg(at)sai(dot)msu(dot)su> 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2001-07-16 15:09:01 Re: Planned changes to pg_am catalog
Previous Message Oleg Bartunov 2001-07-16 14:46:49 Re: Planned changes to pg_am catalog