Null-safe GiST interface (proposal)

Hi,

we're getting back to GiST development and would like to discuss
our plans for 7.2. This discussion doesn't touch any changes in system tables
to solve index_formtuple problem.
We want to discuss implementation of null-safe interface to GiST
(for reference see thread http://fts.postgresql.org/db/mw/msg.html?mid=1025848 )

There are seven user-defined functions one should write to create GiST opclass:

1. equal - it's already null-safe. GiST core will not call 'equal'
function if any parameter is NULL

2,3. compress/decompress - always return NULL for NULL, so we could also
handle them inside GiST core as for 'equal'

4. penalty - accepts 2 parameters and never returns NULL. In existed
implementations we've seen penalty returns 0 (zero) if
any of the parameters is NULL. For this case we propose
not to call 'penalty' if it's marked as isstrict.

5. consistent - returns 'false' if any of the parameters is NULL.
it never returns NULL.

6. union - accepts array of keys and returns their union. If all keys are NULL
then returns NULL, so we don't need to call this function.
If not all keys are NULL we could:
a) Clean up NULLs from array
b) don't touch this array and require 'union' function to
handle NULL's. In this case we need an additional array
to point NULLs if we want to support parameters pass-by-value

7. picksplit - accepts structure GIST_SPLITVEC and array of keys. It never
returns NULL.
there are 2 variants:
a) Clean up NULLs from array
don't need to change existed opclasses
b) Require 'picksplit' to handle NULL'
To support arguments passed by value we need additional
array as in case 6.b

Summary:

1. Only for one function - penalty, 'isstrict' mark could be required.
in that case 'penalty' will be not called for NULL keys,
otherwise, it's users responsibility to write null-safe code.
Other functions could be handled inside GiST core without
bothering of user. This is quite easy task.

2. For union and picksplit we propose to clean up NULLs from array of
keys, so support of arguments 'passed-by-value' will not require
changes of user interface. It would require some modification of current
algorithm of splitting, but this wouldn't be a complex task for us.

Proposed solution solves the problem with 'pass-by-value' interface,
while we don't see where it could be used because in GiST
key for index type of int4 is 8-byte.

Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg(at)sai(dot)msu(dot)su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83