Re: Accessing original TupleDesc from SRF - Mailing list pgsql-hackers

From Joe Conway
Subject Re: Accessing original TupleDesc from SRF
Date
Msg-id 3D6F9054.5020900@joeconway.com
Whole thread Raw
In response to Accessing original TupleDesc from SRF  (John Gray <jgray@azuli.co.uk>)
Responses Re: Accessing original TupleDesc from SRF  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Accessing original TupleDesc from SRF
Next
From: "Iavor Raytchev"
Date:
Subject: pgaccess - where to store the own data