Skip site navigation (1) Skip section navigation (2)

Re: Problem with DirectFunctionCall3(array_in,...)

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: (view raw, whole thread or download thread mbox)
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

In response to


pgsql-novice by date

Next:From: Volkan YAZICIDate: 2005-04-30 21:07:38
Subject: connection status and lo
Previous:From: Michael FuhrDate: 2005-04-30 15:48:26
Subject: Re: Problem with DirectFunctionCall3(array_in,...)

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group