On Thu, 21 Dec 2000, Tom Lane wrote:
> Date: Thu, 21 Dec 2000 11:32:47 -0500
> From: Tom Lane <[EMAIL PROTECTED]>
> To: Oleg Bartunov <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Subject: [HACKERS] Re: equal operator for _int4 (array of int4)
>
> Oleg Bartunov <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
