On Sat, Jan 8, 2011 at 9:12 PM, Jeff Davis <pg...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
