Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> writes: > On 21.09.2011 18:46, Tom Lane wrote: >> Well, we'd have to negotiate what the API ought to be. What I'm >> envisioning is that datatypes could provide alternate comparison >> functions that are designed to be qsort-callable rather than >> SQL-callable. As such, they could not have entries in pg_proc, so >> it seems like there's no ready way to represent them in the catalogs.
> Quite aside from this qsort-thing, it would be nice to have versions of > all simple functions that could be called without the FunctionCall > overhead. Hmm, that's an interesting idea. I think probably the important aspects are (1) known number of arguments and (2) no null argument or result values are allowed. Not sure what we'd do with collations though. > We could have an extended version of the PG_FUNCTION_INFO_V1 macro that > would let you register the fastpath function: > PG_FUNCTION_INFO_V1(int4pl, int4pl_fastpath); We don't use PG_FUNCTION_INFO_V1 for built-in functions ... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers