Tom Lane wrote:
> Definitely better. I'd suggest also thinking about whether the
> same/similar macros can support functions that return a set of a
> scalar (non-tuple) datatype. In my mind, the cleanest design would
> be some base macros that support functions-returning-set (of anything),
> and if you want to return a set of scalar then you just use these
> directly (handing a Datum to FUNC_RETURN_NEXT). If you want to return
> a set of tuples then there are a couple extra steps that you need to
> do to build a tupdesc, build a tuple, and convert the tuple to Datum
> (which at the moment you do by putting it into a slot, but I think we
> ought to change that soon). If it were really clean then the macros
> supporting these extra steps would also work without the SRF macros,
> so that you could use 'em in a function returning a single tuple.
>
Sorry for the long delay. I just got back to this today, and I've run
into an interesting question.
I have a proposal and patch almost ready which I think pretty much meets
the above design requirements. I also wanted to incorporate a built-in
function for returning guc variables (varname text, varval text),
consistent with previous posts. This is both useful and a good test of
the Composite & SRF function API (the API includes functions/macros to
facilitate returning composite types, and an independent set of
functions/macros for returning sets, whether composite or scalar).
The question is how to best bootstrap this new function. In order to
create the pg_proc entry I need the return type oid. If I understand
correctly, in order to get a composite return type, with a known oid, I
would need to create a bootstrapped relation and the corresponding
bootstrapped pg_type entry.
Is there any alternative? It seems ugly to bootstrap so many objects for
every (future) builtin function which returns a composite type.
Thanks,
Joe
