From: | "Andrew Dunstan" <andrew(at)dunslane(dot)net> |
---|---|
To: | <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: generic builtin functions |
Date: | 2005-11-10 22:19:16 |
Message-ID: | 2224.24.211.165.134.1131661156.squirrel@www.dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane said:
> Andrew Dunstan <andrew(at)dunslane(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2005-11-10 22:26:45 | Re: generic builtin functions |
Previous Message | David Fetter | 2005-11-10 22:14:08 | Re: generic builtin functions |