Tom Lane wrote:
>
> Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:
> > Whenever I'm tempted to have concurrent arrays like this I always pull
> > back because it seems to lead to major pain later. For example, I can
> > see situations where I'd like to pass an argument around together with
> > it's is-null information...
>
> That's not an unreasonable point ... although most of the existing code
> that needs to do that seems to need additional values as well (the
> datum's type OID, length, pass-by-ref flag are commonly needed).
> Something close to the Const node type is what you tend to end up with.
> The fmgr interface is (and should be, IMHO) optimized for the case where
> the called code knows exactly what it's supposed to get and doesn't need
> the overhead info.
It may be true for C functions, but functions in higher level languages
often like to be able to operate on several types of arguments (or at least
to operate on both NULL and NOT NULL args)
> In particular, the vast majority of C-coded functions in the backend
> should be marked 'strict' in pg_proc, and will then not need to bother
> with argnull at all...
But the main aim of fmgr redesign is imho _not_ to make existing functions
work better but to enable a clean way for designing new functions/languages.
I'm probably wrong, but to me it seems that the current proposal solves only
the problem with NULLs, and leaves untouched the other problem of arbitrary
restrictions on number of arguments (unless argcount > MAX is meant to be
passed using VARIABLE i.e. -1)
------------------------
Hannu
