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
return4;
}
int bar(FuncArg a, FuncArg b) { if (a.argnull || !b.argnull) return 0 else return INT32(a.arg) ~
INT32(b.arg);
}
