> 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
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
