Re: revised sample SRF C function; proposed SRF API

Joe Conway <mail(at)joeconway(dot)com> writes:
> If not, prepare an array of C strings representing the
> attribute values of your return tuple, and call:
> FUNC_BUILD_SLOT(values, funcctx);

I think that's a poor choice of abstraction, as it forces the user into
the least-efficient-possible way of building a return tuple. What if
he's already got a tuple (eg, he read it off disk), or at any rate has
datums already in internal format? I'd say make it

FUNC_RETURN_NEXT(funcctx, HeapTuple)

and let the caller worry about calling heap_formtuple or otherwise
constructing the tuple.

For similar reasons I think the initial call ought to provide a
TupleDesc structure, not a relation name (which is at least two lookups
removed from the information you actually need).

The max_calls thing doesn't seem quite right either; at least not as
something that has to be provided in the "first line after the function
declarations". It might be quite expensive to derive, and you don't
need to do so on every call. Perhaps better have the macro return a
boolean indicating whether this is the first call or not, and then
people can do

if (FUNC_MULTIPLE_RESULT(funcctx))
{
// do one-time setup here,
// including possibly computing a max_calls value;
// also find or make a TupleDesc to be stored into the
// funcctx.
}

Similarly I'm confused about the usefulness of misc_ctx if it has to be
re-provided on every call.

regards, tom lane