BTW,
Moreover, I would like xpath_string() which return
On 1/29/07, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
[...]
So, while I realize that I've been arguing for a lean core recently, I
want to propose that we add a small set of XPath support functions to
the core. This would come down to approximately the following set
xpath_boolean(query, xml)
xpath_number(query, xml)
xpath_string(query, xml)
xpath_nodeset(query, xml) -- API and return type still unclear
As for the latest one, I am for xml[] as a result type, especially if
we have xpath* in contrib. This is not XQuery sequences, but at least
it allows user to see all XML fragments (and manage them somehow -- if
he wants, he would concatenate them to one value using corresponding
function).
As for #1-3 -- they are very simple things; I do not like them,
because they return only one scalar value, which is the one
encountered first. I do not think it's very useful functions at all...
Moreover, in case of xpath_string() I think it should work in the
following manner:
1. Find all nodes that correspond the expression given. In general
case it will be a set of nodes; OK, let's take only the first one, as
we do with other functions...
2. For this node retrieve all text nodes that are its descendant. It
will be an ordered set of text values.
3. Concatenate all these values and return as a single string.
I suppose, only such behaviour is in compliance with XML data model --
as an example, consider following XML fragment: '<a>most
<b>advanced</b> open source database</a>'.
So, for xpath_string() I see two issues -- 1) a lack of usability if
it returns only one (the first) value from possible sequences of
values; 2) bad conformance if it take only one text node which belongs
to the first context node.
BTW, maybe it would be useful to have several functions, with every
behaviour that can be useful.
Also, I think it'd be better not to use the word "query" speaking of
XPath, "XPath expression" is much better (to avoid confusion with XML
Query).
We also have prospects that later on we might get fancy GIN-based
indexing support for XPath, which might need another xpath_matches()
function or operator of some kind.
Now I'm trying to collect all thought regarding indexes and express it
in a short message (what types of queries should be considered; what
types of indexes would support that queries).
BTW, Do not forget that some type of index is already available - it's
simply functional indexes on xpath_*() with static (i.e. known as a
constant value a priori) XPath expression.
As far as contrib/xml2 is concerned, I'm not going to make any efforts
to make the interface compatible because that module has a rather
pragmatic design, whereas I'd rather just provide the raw operations
that can be assembled easily by the user to achieve some of the things
that contrib/xml2 does now. Once some description of transition steps
has been developed, I'd deprecate the contrib/xml2 module and probably
remove it after 8.3.
In the wiki we have collected some random ideas of other interesting
operations on XML types
(http://developer.postgresql.org/index.php/XML_Todo, near the bottom).
That list at the moment says:
DTD validation
Relax-NG
XSLT
XML Canonical (to compare XML values)
Pretty-printing XML (e.g., indenting)
I've added "Shredding with annotated schemas" to this list (with brief
description why it could be needed).
Also, in a long term I see such items as
- integration/support in pl/perl and other pl-langs that can work with XML;
- work with web services (maybe it'd better to use pl/perl here).
Maybe it too early to add such things even to the bottom of Todo list :-)
--
Best regards,
Nikolay
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
