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 12878.958972515@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:
> 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.  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...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Chris Bitmead
Date:
Subject: Re: Last call for comments: fmgr rewrite [LONG]
Next
From: "Robert B. Easter"
Date:
Subject: Re: Thus spoke SQL3 (on OO)