
> Please correct me if I've got this wrong, but it appears from the SRF
> API, that a SRF cannot readily refer to the TupleDesc to which it is
> expected to conform (i.e. the TupleDesc derived from the FROM 
> clause of
> an original SELECT statement) because that is held in the 
> executor state
> and not copied or linked into the function context.
> 
> The reason I'm interested (and this might be a crazy idea) is that a
> function might choose to adapt its output based on what it is 
> asked for.
> i.e. the attribute names and types which it is asked to provide might
> have some significance to the function. 
> 
> The application in this case is the querying of an XML document (this
> relates to the contrib/xml XPath functions) where you might want a
> function which gives you a "virtual view" of the document. In order to
> do so, you specify a query such as:
> 
> SELECT * FROM xmlquery_func('some text here') AS xq(document_author
> text, document_publisher text, document_date text);
> 
> (this would likely be part of a subquery or join in practice.)
> 
> The function would see the requested attribute "document_author" and
> translate that to '//document/author/text()' for use by the XPath
> engine. This avoids having to have a function with varying arguments
> -instead you have a 'virtual table' that generates only the attributes
> requested.
> 
> Does this sound completely crazy?

Nope, sounds really useful.

Andreas

Fri, 30 Aug 2002 13:55:37 +0200
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>
Re: Accessing original TupleDesc from SRF