Re: Last call for comments: fmgr rewrite [LONG] - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Last call for comments: fmgr rewrite [LONG]
Date
Msg-id 11675.958954577@sss.pgh.pa.us
Whole thread Raw
In response to Re: Last call for comments: fmgr rewrite [LONG]  (Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>)
List pgsql-hackers
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).  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


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Last call for comments: fmgr rewrite [LONG]
Next
From: Chris Bitmead
Date:
Subject: Re: Berkeley DB...