I think that the proposals for the revision of the function interface
are all an improvement on what is there, and I hope to try to find time
to help implement whatever is decided. Here are some more thoughts in
relation to the question of set valued and tuple valued (or complex
type?) arguments.
Another place that user defined functions are used in the PostgreSQL
backend is in association with access methods. Both as boolean
operators for search predicates, and as auxiliary functions for the
access methods. Allowing set valued and tuple valued arguments and
return values for functions and operators in this setting can be
valuable.
For instance, suppose I have a table t that stores geometric objects in
some space, and I have a spatial index such as R*-tree, or even a GIST
index. Given a set of points pts I want to do a query of the form
SELECT * FORM t WHERE t.object <intersects> pts;
Under these circumstances it would be really nice to be able to pass a
set of objects (as an SPI tuple table for instance) into the index.
Currently, the way I do this (with a custom access method) is to create
a temp table, put the key set into the temp table, and pass the name of
the temp table to the access method in the search key. The access
method then does an SPI select on the temp table and stores the returned
items into the private scan state for use during the scan.
While I realize that implementing this example requires much more than a
change to the function interface, I hope that it illustrates that it is
perhaps a good idea to keep as much flexibility in the function
interface as possible.
Bernie Franpitt
