Re: generic builtin functions - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: generic builtin functions
Date
Msg-id 2224.24.211.165.134.1131661156.squirrel@www.dunslane.net
Whole thread Raw
In response to Re: generic builtin functions  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: generic builtin functions  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane said:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> My idea was to have the functions that need access to the text values
>> look up fcinfo->flinfo->fn_oid and then use that to look up the type
>> info. But that would mean we would need pg_proc entries for these
>> functions for each enum, even if it's the same function underneath,
>> wouldn't it?
>
> Yeah, and you still have to have a pg_proc entry for the original
> underlying function, else it doesn't get into the builtins list.
>
> It's worth pointing out also that while aliasing a builtin function
> after-the-fact like that is possible, lookup for it is substantially
> slower than a normal builtin (because we can't do a binary search on
> OID for it).  That's on top of the function-to-type-oid lookup you'll
> have to do within the function.
>
> I'm not convinced that using bigint-equivalent space for an enum is a
> mortal sin...
>

What about having the calling code fill in the io type oid in an extra field
in the flinfo? That possibly still leaves the builtin/aliasing issue ...
that deserves more thought. There's no rush on this.

cheers

andrew





pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: generic builtin functions
Next
From: Tom Lane
Date:
Subject: Re: generic builtin functions