Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)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
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
In response to
pgsql-hackers by date
|Next:||From: Daniel Vázquez||Date: 2011-09-21 16:28:53|
|Subject: unaccent contrib|
|Previous:||From: Tom Lane||Date: 2011-09-21 16:23:13|
|Subject: Re: Inlining comparators as a performance optimisation |