Re: Problem with DirectFunctionCall3(array_in,...)
От | Michael Fuhr |
---|---|
Тема | Re: Problem with DirectFunctionCall3(array_in,...) |
Дата | |
Msg-id | 20050430154826.GA49322@winnie.fuhr.org обсуждение исходный текст |
Ответ на | Problem with DirectFunctionCall3(array_in,...) (Jessica Ditt <jessica.ditt@web.de>) |
Ответы |
Re: Problem with DirectFunctionCall3(array_in,...)
|
Список | pgsql-novice |
On Thu, Apr 28, 2005 at 02:11:29PM +0200, Jessica Ditt wrote: > > DirectFunctionCall3(array_in, CStringGetDatum(arraystring), > ObjectIdGetDatum(20), Int32GetDatum(-1)); > > unfortunately smashes my postmaster... Running a debugger on the core dump shows a segmentation fault at the following line in array_in() in arrayfuncs.c: my_extra = (ArrayMetaState *) fcinfo->flinfo->fn_extra; 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. I don't know if the following is The Right Way To Do It, but it works for me in simple tests: Datum a; a = OidFunctionCall3(F_ARRAY_IN, CStringGetDatum(arraystring), ObjectIdGetDatum(INT8OID), -1); F_ARRAY_IN is defined in utils/fmgroids.h; INT8OID is defined in catalog/pg_type.h. Before using the above code, you might want to see if one of the developers follows up. There might be a different way that's considered best practice. -- Michael Fuhr http://www.fuhr.org/~mfuhr/
В списке pgsql-novice по дате отправления: