Thread: 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