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
returns0 (zero) if            any of the parameters is NULL. For this case we propose            not to call 'penalty'
ifit'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'tneed 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
anadditional 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
are2 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
NULLkeys,   otherwise, it's users responsibility to write null-safe code.   Other functions could be handled inside
GiSTcore  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
algorithmof 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@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83