Tom Lane wrote:
> I've been thinking more about this, and wondering if we should not
> only make the tupdesc available but rely more heavily on it than we
> do. Most of the C-coded functions do fairly substantial pushups to
> construct tupdescs that are just going to duplicate what
> nodeFunctionscan already has in its back pocket. They could save some
> time by just picking that up and using it.
>
> On the other hand, your experience yesterday with debugging a mismatched
> function declaration suggests that it's still a good idea to make the
> functions build the tupdesc they think they are returning.
In a function which *can* know what the tupledec should look like based
on independent information (contrib/tablefunc.c:crosstab), or based on a
priori knowledge (guc.c:show_all_settings), then the passed in tupdesc
could be used by the function to validate that it has been acceptably
declared (for named types) or called (for anonymous types).
But it is also interesting to let the function try to adapt to the way
in which it has been called, and punt if it can't deal with it. And in
some cases, like John's example, there *is* no other way.
Joe