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