Stefan Niantschur <[EMAIL PROTECTED]> writes:
> Please find below the most recent code snippet. It is mainly based on
> examples from the pg documentation:
> -------8< -------
> #define GET_TEXT(cstrp) DatumGetTextP(DirectFunctionCall1(textin,
> CStringGetDatum(cstrp)))
> (...)
> char *cres;
> int ret;
> (...)
> if ((ret = SPI_connect()) < 0)
> {
> elog(ERROR, "get_info: SPI_connect returned %d", ret);
> }
> proc = SPI_processed;
> initStringInfo(&result_buf);
> if (ret > 0 && SPI_tuptable != NULL)
> {
> TupleDesc tupdesc = SPI_tuptable->tupdesc;
> SPITupleTable *tuptable = SPI_tuptable;
> int i,k;
> for (i = 0; i < proc; i++)
> {
> HeapTuple tuple = tuptable->vals[i];
> for (k = 1; k <= tupdesc->natts; k++)
> {
> cres = SPI_getvalue(tuple, tupdesc, k);
> appendStringInfo(&result_buf, SPI_getvalue(tuple, tupdesc, k));
> elog(INFO, "info: %s", cres);
> }
> }
> }
> SPI_finish();
> elog(INFO, "---");
> PG_RETURN_TEXT_P(GET_TEXT(result_buf.data));
> ------->8 -------
> I still have the problem that I can use the C function via
> select from within psql if the result is not too long.
I don't think length has anything to do with it; rather the problem is
that you're trying to return data that's already been pfree'd when you
did SPI_finish().
Probably the simplest fix for this case is to put the initStringInfo
call before SPI_connect, so that the result_buf.data buffer exists
in the outer function context and not in the temporary SPI context.
BTW, it is strongly advisable to do development/testing of C code
in a backend that's been built with --enable-cassert. Had you done
so, this mistake would have been much more obvious.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
