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

Bruce Momjian wrote:
>
> > Tom Lane wrote:
> >
> > > No, because we aren't ever going to be dynamically allocating these
> > > things; they'll be local variables in the calling function.
> >
> > Fair enough then. Although that being the case, I don't see the big deal
> > about using a few more bytes of stack space which costs absolutely
> > nothing, even though the binary compatibility is a small but still real
> > advantage.
>
> I like Tom's clean design better. Flexibility for little payback
> usually just messes up clarity of the code.

I tend to think grouping data that belongs together as by definition
"clean". 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...

struct FuncArg
{
Datum arg;
bool argnull;
};

typedef struct
{
struct FuncArg args[];
} FunctionCallInfoData;

Datum someFunc(FunctionCallInfo fcinfo)
{
return INT32(foo(fcinfo.args[0]) +
bar(fcinfo.args[1], fcinfo.args[2]));
}

int foo(FuncArg a) {
if (a.argnull && INT32(a.arg) > 0 ||
(!a.argnull && INT32(a.arg <= 0)
return 3;
else
return 4;
}

int bar(FuncArg a, FuncArg b) {
if (a.argnull || !b.argnull)
return 0
else
return INT32(a.arg) ~ INT32(b.arg);
}