XML type and XPath

Now that the xml type as per SQL:2003 is pretty much finished, one
starts to wonder about what useful things one might do with it. What
we have so far contains only functions to construct XML values from SQL
data, but there is nothing that you can do with the type at the moment
except look at it.

The basic kind of operation on XML values is XPath queries. This is the
equivalent of what substring/position/length/concat/etc. does for text
types, and it's also the gist of the contrib/xml2 module, and it's
typically provided by other DBMS with "XML support". SQL:2003 says
nothing on the matter, whereas SQL:2006 specifies XQuery support, but I
don't think we can implement that at the moment because there is no
library available to do it. (XPath is in libxml2.)

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

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.

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 would argue for keeping these sort of things in a non-core module or a
PgFoundry repository.

Comments?

--
Peter Eisentraut
http://developer.postgresql.org/~petere/