On Wed, Sep 21, 2011 at 4:46 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > 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.
Why couldn't they be in pg_proc with a bunch of opaque arguments like the GIST opclass support functions? I'm a bit puzzled what the arguments would look like. They would still need to know the collation, nulls first/last flags, etc. And calling it would still not be inlinable. So they would have to check those flags on each invocation instead of having a piece of straightline code that hard codes the behaviour with the right behaviour inline. ISTM the hope for a speedup from the inlining mostly came from the idea that the compiler might be able to hoist this logic outside the loop (and I suppose implement n specialized loops depending on the behaviour needed). -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
