From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Chris Bitmead <chrisb(at)nimrod(dot)itg(dot)telstra(dot)com(dot)au> |
Cc: | chris(at)bitmead(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Last call for comments: fmgr rewrite [LONG] |
Date: | 2000-05-22 03:28:31 |
Message-ID: | 12233.958966111@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Chris Bitmead <chrisb(at)nimrod(dot)itg(dot)telstra(dot)com(dot)au> writes:
> Tom Lane wrote:
>> I did consider that but it's probably not worth near-doubling the size
>> of the struct (think about how that will pack, especially if Datum
>> becomes 8 bytes).
> But FUNC_MAX_ARGS is currently 16. 98% of functions are probably 1 or 2
> arguments. So your way you always use 144 bytes. With my proposal most
> will use 16 or 32 bytes because of the variable struct size and you
> won't have an arbitrary limit of 16 args.
No, because we aren't ever going to be dynamically allocating these
things; they'll be local variables in the calling function. Typical
code looks like this:
static Datum
ExecMakeFunctionResult(Node *node, List *arguments, ExprContext *econtext,
bool *isNull, bool *isDone)
{
FunctionCallInfoData fcinfo;
Datum result;
MemSet(&fcinfo, 0, sizeof(fcinfo));
/* ... fill non-defaulted fields of fcinfo here ... */
result = FunctionCallInvoke(&fcinfo);
*isNull = fcinfo.isnull;
return result;
}
To take advantage of a variable-length struct we'd need to do a palloc,
which is pointless and slow. The only reason I care about the size of
the struct at all is that I don't want that MemSet() to take longer
than it has to. (While I don't absolutely have to zero the whole
struct, it's simple and clean to do that, and it ensures that unused
fields will have a predictable value.)
Bottom line is that there *will* be a FUNC_MAX_ARGS limit. The only
question is whether there's any point in making the binary-level API
for called functions be independent of the exact value of FUNC_MAX_ARGS.
I kinda doubt it. There are a lot of other things that are more likely
to vary across installations than FUNC_MAX_ARGS; I don't see this as
being the limiting factor for portability.
> Well if anybody ever wanted to do it, not having to re-write every
> function in the system would be a nice win.
We already did the legwork of not having to rewrite anything. It's
only a config.h twiddle and recompile. I think that's plenty close
enough...
>>>> Wondering if some stub code generator might be appropriate so that
>>>> functions can can continue to look as readable as before?
>>
>> Er, did you read to the end of the proposal?
> Yep. Did I miss your point?
Possibly, or else I'm missing yours. What would a stub code generator
do for us that the proposed GETARG and RETURN macros won't do?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Chris Bitmead | 2000-05-22 03:46:22 | Re: Last call for comments: fmgr rewrite [LONG] |
Previous Message | Bruce Momjian | 2000-05-22 03:11:00 | Re: Berkeley DB... |