From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Fuhr <mike(at)fuhr(dot)org> |
Cc: | Jessica Ditt <jessica(dot)ditt(at)web(dot)de>, pgsql-novice(at)postgresql(dot)org |
Subject: | Re: Problem with DirectFunctionCall3(array_in,...) |
Date: | 2005-04-30 16:52:43 |
Message-ID: | 6632.1114879963@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-novice |
Michael Fuhr <mike(at)fuhr(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Volkan YAZICI | 2005-04-30 21:07:38 | connection status and lo |
Previous Message | Michael Fuhr | 2005-04-30 15:48:26 | Re: Problem with DirectFunctionCall3(array_in,...) |