Tom,

while porting our patches for GiST from 7.0.3 to 7.1 we
got a problem with equal operator for _int4 - 
src/backend/access/gist.c:540

        /* did union leave decompressed version of oldud unchanged? */
        FunctionCall3(&giststate->equalFn,
                                  PointerGetDatum(ev0p->pred),
                                  PointerGetDatum(datum),
                                  PointerGetDatum(&result));

this call produces core when one of the PointerGetDatum(ev0p->pred)
or PointerGetDatum(datum) is NULL

We use internal postgres function for array comparison -
 &giststate->equalFn is references to array_eq

There is no problem in 7.0.3

Do you have any idea what could be a reason for such behaivour ?
(bug or feature :-)

  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


Thu, 21 Dec 2000 19:20:44 +0300 (GMT)
Oleg Bartunov <oleg@sai.msu.su>
equal operator for _int4 (array of int4)
Oleg Bartunov <oleg@sai.msu.su> writes:
> this call produces core when one of the PointerGetDatum(ev0p->pred)
> or PointerGetDatum(datum) is NULL
> We use internal postgres function for array comparison -
>  &giststate->equalFn is references to array_eq

array_eq is marked strict, so it's not expecting to get a NULL input.

It's impossible to pass a true SQL NULL through FunctionCall3() anyway
--- no, a null pointer is not an SQL null.  So if you want to use
a coding convention that equates null pointer with SQL null, you'll
have to implement that within your own code and avoid calling array_eq
when you have a null.

IIRC, the rtree and/or gist index types are fairly sloppy about this
point at the moment.  I do not like that, because I do not think an
index type should depend on the assumption that all datatypes it can
handle are pass-by-reference.  If you're going to support nulls then
there needs to be a separate isnull flag for each datum, *not* an
assumption that all-zero-bits can't be a valid datum value.  But I
didn't get around to changing the code yet.

			regards, tom lane

Thu, 21 Dec 2000 11:32:47 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: equal operator for _int4 (array of int4) 
On Thu, 21 Dec 2000, Tom Lane wrote:

> Date: Thu, 21 Dec 2000 11:32:47 -0500
> From: Tom Lane <tgl@sss.pgh.pa.us>
> To: Oleg Bartunov <oleg@sai.msu.su>
> Cc: pgsql-hackers@postgresql.org
> Subject: [HACKERS] Re: equal operator for _int4 (array of int4) 
> 
> Oleg Bartunov <oleg@sai.msu.su> writes:
> > this call produces core when one of the PointerGetDatum(ev0p->pred)
> > or PointerGetDatum(datum) is NULL
> > We use internal postgres function for array comparison -
> >  &giststate->equalFn is references to array_eq
> 
> array_eq is marked strict, so it's not expecting to get a NULL input.
> 
> It's impossible to pass a true SQL NULL through FunctionCall3() anyway
> --- no, a null pointer is not an SQL null.  So if you want to use
> a coding convention that equates null pointer with SQL null, you'll
> have to implement that within your own code and avoid calling array_eq
> when you have a null.

ok. one check isn't difficult to add :-)

> 
> IIRC, the rtree and/or gist index types are fairly sloppy about this
> point at the moment.  I do not like that, because I do not think an
> index type should depend on the assumption that all datatypes it can
> handle are pass-by-reference.  If you're going to support nulls then
> there needs to be a separate isnull flag for each datum, *not* an
> assumption that all-zero-bits can't be a valid datum value.  But I
> didn't get around to changing the code yet.
> 

Tom, this task is too complex for our current understanding of postgres 
internals. What will happens if we ignore NULLs ? We need to provide
vacuum some information about numbers of NULL values.

	Oleg

> 			regards, tom lane
> 

_____________________________________________________________
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


Thu, 21 Dec 2000 19:48:50 +0300 (GMT)
Oleg Bartunov <oleg@sai.msu.su>
Re: Re: equal operator for _int4 (array of int4) 
Oleg Bartunov <oleg@sai.msu.su> writes:
> What will happens if we ignore NULLs ?

Same thing that happens with hash:

regression=# create table foo (f1 int);
CREATE
regression=# create index fooi on foo using hash (f1);
CREATE
regression=# insert into foo values(1);
INSERT 292677 1
regression=# insert into foo values(null);
INSERT 292678 1
regression=# vacuum foo;
NOTICE:  Index fooi: NUMBER OF INDEX' TUPLES (1) IS NOT THE SAME AS HEAP' (2).
        Recreate the index.
VACUUM

> We need to provide vacuum some information about numbers of NULL values.

Preferably without hardwiring assumptions about the behavior of
different index types into VACUUM.

That cross-check in VACUUM has really caused way more grief than it's
worth.  I'm beginning to wonder if we should just take it out...

			regards, tom lane

Thu, 21 Dec 2000 13:09:38 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Re: equal operator for _int4 (array of int4) 