Michael Fuhr <mike@fuhr.org> writes:
> Examining the data shows that fcinfo->flinfo is NULL; presumably
> dereferencing it caused the segmentation fault. Looking at the
> code for DirectFunctionCall3() in fmgr.c, we see that it initializes
> fcinfo by calling InitFunctionCallInfoData() with the second argument
> set to NULL, which gets assigned to flinfo. Apparently that's the
> problem.
This is the intended and documented behavior --- see fmgr/README:
: The DirectFunctionCallN routines will not bother to fill in
: fcinfo->flinfo (indeed cannot, since they have no idea about an OID for
: the target function); they will just set it NULL.
It would maybe be possible for them to create an only-partially-valid
flinfo, but I think that would simply lead to easier-to-miss bugs.
In any case it'd be a waste of cycles in the vast majority of calls.
Realistically you don't want to call array_in this way anyhow, since
its setup overhead is so high. You want to have a flinfo struct for it
that will persist for the entire query, if at all possible. That is
you want one fmgr_info() call and then a series of FunctionCallN() calls.
regards, tom lane
