Re: handling NULLS in GiST - Mailing list pgsql-hackers

From Oleg Bartunov
Subject Re: handling NULLS in GiST
Date
Msg-id Pine.GSO.4.33.0107161832240.24835-100000@ra.sai.msu.su
Whole thread Raw
In response to Re: handling NULLS in GiST  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: handling NULLS in GiST
List pgsql-hackers
On Mon, 16 Jul 2001, Tom Lane wrote:

> Oleg Bartunov <oleg@sai.msu.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.)

We also would like to handle NULLs. All our codes handle NULLs properly.
contrib/cube is just a bad example :-) In any case if you give an
interface to developer it's his responsibility to be aware of possible
errors. Developer has always a possibility to divide by zero.
We could change contrib/cube to be null-safe.
Also multikey split algorithm uses NULL to mark secondary (...) keys
in tuple for optimization of page splitting and we don't like idea to
rewrite algorithm. GiST interface functions (split, union -
user-level functions) have a pointer to operand vector as argument.
Operand vector can't be a NULL, but some operands in the vector could
be NULL.


>
> 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".

vaguely understand :-) DirectFunctionCallN are already interface to
opclass support routines. Do we need to build on yet another interface
just to mark bad users routines ? What should we do with that 'strict'
mark ?


>
> But that's a micro-issue.

agreed, but I'd like to require people write null-safe contribs
and remove your stopper.

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?

if you mean first NULL keys in multikey GiST than just remove this tuple
from index because it's informativeless. btw, what btree does ?



>             regards, tom lane
>
Regards,    Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Planned changes to pg_am catalog
Next
From: "Rod Taylor"
Date:
Subject: ALTER TABLE ADD COLUMN column SERIAL -- unexpected results