Re: [HACKERS] revised sample SRF C function; proposed SRF API

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.

As promised on HACKERS, here's the Composite and SRF function API patch.
Included is a new builtin guc function, exported as show_all_vars(). In
order to avoid creating a new bootstrapped relation, I made the pg_proc
entry specify 0 as the function return type, and then fixed it in
initdb.sh as follows:

$ECHO_N "setting return type for composite returning functions... "$ECHO_C

"$PGPATH"/postgres $PGSQL_OPT template1 >/dev/null <<EOF
CREATE VIEW pg__guc AS \
SELECT \
''::text as varname, \
''::text as varval;

UPDATE pg_proc SET \
prorettype = (SELECT oid FROM pg_type WHERE typname = 'pg__guc') \
WHERE \
proname = 'show_all_vars';

EOF
if [ "$?" -ne 0 ]; then
exit_nicely
fi
echo "ok"

Any concerns with this approach? Is it too much of a hack, or
preferrable to adding new bootstrapped relations solely for this purpose?

Thanks,

Joe