From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Oleg Bartunov <oleg(at)sai(dot)msu(dot)su> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: equal operator for _int4 (array of int4) |
Date: | 2000-12-21 16:32:47 |
Message-ID: | 16802.977416367@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Oleg Bartunov <oleg(at)sai(dot)msu(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Oleg Bartunov | 2000-12-21 16:48:50 | Re: Re: equal operator for _int4 (array of int4) |
Previous Message | Oleg Bartunov | 2000-12-21 16:20:44 | equal operator for _int4 (array of int4) |