Tom Lane wrote:
>
> Chris Bitmead <chrisb@nimrod.itg.telstra.com.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).
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.
> 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.
Well if anybody ever wanted to do it, not having to re-write every
function in the system would be a nice win. Maybe there are other wins
we don't see yet in not having a fixed limit?
> 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.
Hmm. Looks like a possible future win to me. Anybody who has a library
of functions might not have to recompile.
> > 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?
