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

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