Skip site navigation (1) Skip section navigation (2)

Accessing original TupleDesc from SRF

From: John Gray <jgray(at)azuli(dot)co(dot)uk>
To: Hackers List <pgsql-hackers(at)postgresql(dot)org>
Subject: Accessing original TupleDesc from SRF
Date: 2002-08-30 11:45:54
Message-ID: 1030707957.2072.94.camel@adzuki (view raw or flat)
Thread:
Lists: pgsql-hackers
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?

Regards

John

-- 
John Gray	
Azuli IT	
www.azuli.co.uk	



Responses

pgsql-hackers by date

Next:From: Zeugswetter Andreas SB SDDate: 2002-08-30 11:55:37
Subject: Re: Accessing original TupleDesc from SRF
Previous:From: Nigel J. AndrewsDate: 2002-08-30 11:22:01
Subject: Re: Fulltextindex

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group