From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: generic builtin functions |
Date: | 2005-11-10 20:36:41 |
Message-ID: | 11634.1131655001@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Martijn van Oosterhout | 2005-11-10 20:42:39 | Re: generic builtin functions |
Previous Message | Merlin Moncure | 2005-11-10 20:35:38 | 8.0 -> 8.1 dump duplicate key problem? |