Обсуждение: equal operator for _int4 (array of int4)

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

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

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

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