Re: generic builtin functions

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

In response to

Responses

Browse pgsql-hackers by date

  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