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
return4;
 
}

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