Re: Last call for comments: fmgr rewrite [LONG]

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Chris Bitmead <chrisb(at)nimrod(dot)itg(dot)telstra(dot)com(dot)au>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Last call for comments: fmgr rewrite [LONG]
Date: 2000-05-22 05:15:15
Message-ID: 12878.958972515@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:
> 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Robinson 2000-05-22 06:39:46 A test to add to the crashme test
Previous Message Tom Lane 2000-05-22 04:46:18 Re: Last call for comments: fmgr rewrite [LONG]