On Sat, Jan 8, 2011 at 9:12 PM, Jeff Davis <pgsql@j-davis.com> wrote:
>> Oh, hmm. What generic functions did you have in mind?
>
> Well, input/output, comparisons, overlaps, intersection, minus, and all
> the necessary GiST support functions.
>
> Without generic functions, the only choices we have are:
> * force the user to write and specify them all -- which doesn't leave
> much left of my feature (I think the interface would be all that's
> left).
> * somehow generate the functions at type creation time
>
> Any other ideas?
Do they have to be good ideas?
I mean, one semi-obvious possibility is to write one set of C
functions that can have multiple SQL-level definitions bound to it.
Then when the function is called, it can peek at flinfo->fn_oid to
figure out which incarnation was called and then get the typo info
from there. That's ugly, though.
It'd be really nice if we could just arrange for the info on which
type anyrange actually is at the moment to be available in the right
place. Storing it on disk to work around that is pretty horrible, but
maybe there's no other reasonable option.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
