From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | chris(at)bitmead(dot)com |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Last call for comments: fmgr rewrite [LONG] |
Date: | 2000-05-22 00:16:17 |
Message-ID: | 11675.958954577@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:
> Just wondering what the implications of FUNC_MAX_ARGS is, and whether
> something like...
> struct FuncArg
> {
> Datum arg;
> bool argnull;
> };
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). The average callee will probably not be looking at
the argnull array at all, so it won't have a dependency on the offset to
argnull in the first place. Furthermore FUNC_MAX_ARGS is not going to
vanish in the foreseeable future; we have fixed-size arrays in places
like pg_proc and there's just not enough reason to go to the pain of
making those variable-size. So the only possible win would be to make
dynamically loaded functions binary-compatible across installations with
varying FUNC_MAX_ARGS values ... and since that'd matter only if they
looked at argnull *and* not at any other structure that depends on
FUNC_MAX_ARGS, it's probably not worth it.
> 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?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-05-22 00:17:57 | Re: Last call for comments: fmgr rewrite [LONG] |
Previous Message | Chris Bitmead | 2000-05-22 00:15:24 | Re: Postgresql OO Patch |