From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: question re internal functions requiring initdb |
Date: | 2002-07-14 02:25:53 |
Message-ID: | 3D30E131.4030608@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Joe Conway <mail(at)joeconway(dot)com> writes:
>>It made me wonder why don't we always create internal functions this
>>way, or at least all except a core set of bootstrapped functions.
>
> I don't believe it will actually work: you *must* add an internal
> function to include/catalog/pg_proc.h, or it won't get into the function
> lookup table that's built by Gen_fmgrtab.sh.
>
> It is true that you don't have to force an initdb right away, but
> there's an efficiency penalty IIRC (can't bypass the lookup table
> search, or something ... read the fmgr code for details).
>
OK -- I see what you mean now. For a *user alias* of an existing builtin
function fmgr_isbuiltin(), which does a binary search on the sorted
fmgr_builtins array, will fail. So there is a speed penalty in that the
function is looked up with fmgr_lookupByName(), which does a sequential
scan through the fmgr_builtins array.
Regardless, if the function is not listed in the fmgr_builtins array at
all, which it won't be if Gen_fmgrtab.sh doesn't see it in pg_proc.h,
then the lookup will fail entirely. I guess I would have found this out
on my own if I had carried the experiment out a little farther. Shucks!
Joe
From | Date | Subject | |
---|---|---|---|
Next Message | Tim Hart | 2002-07-14 05:09:15 | line datatype |
Previous Message | Tom Lane | 2002-07-14 01:01:46 | Re: question re internal functions requiring initdb |