pg...@mohawksoft.com wrote:
On Tuesday 28 July 2009 23:30:23 pg...@mohawksoft.com wrote:
The thing that perplexed me was that it was not obvious from the docs
how,
exactly, to get the functionality that was simple and straight forward
in
XML2.
I continue to be in favor of adding
xpath_string
xpath_number
xpath_boolean
functions, which would be both easier to use and provide a more
casting-free
approach to pass the data around. In the past there were some doubts and
objections about that, but I think it could be done.
I totally agree, but I tend to be more of a pragmatist than a purist. It
seems to me that purists tend to like a lot of topical consistency in an
API, like the new implementation of xpath over the former. Where as a
pragmatists will violate some of the rules to make something seemingly
more easy.
The issue I have with the xpath implementation is that it seems more
geared to an XML implementation on top of SQL instead of an XML
implementation embedded within SQL.
For instance, I use an XML column in a database for "metadata" about
customers and other objects. So, we have a base table of "objects" and the
specifics of each object is contained within XML.
So, the former API was perfect for this use:
select datum form objects were key ='GUID' and
xpath_string(datum,E'foo/bar') = 'frobozz';
The logic of the function seems is that it is intended to use extracted
XML within a query. The new xpath functionality seems not to be designed
to facilitate this, requiring a pretty arcane query structure to do the
same thing:
select datum from objects where key='GUID' and (xpath(E'foo/bar',
XMLPARSE(CONTENT datum))::text())[1] = 'frobozz';
It's not that arcane. Mike Rylander and I came up with the same answer
independently within a very short time of you posting your query. I
guess it depends how used you are to using XPath.
It's also probably not terribly hard to produce a wrapper to do what
you'd like.
I have no problem with adding some convenience functions. I do have a
problem with functions where we try to make things easy and instead muck
them up. We just ripped out a "convenience" from our xpath processing
that was totally braindead, so this isn't an idle concern.
I would argue that "xpath_string" is a fairly horrible name for what the
xml2 module provides. Specifically, my objection is that an xpath query
returns a nodeset, and what this function returns is not the string
value of the nodeset, but the string value of the *contents* of those
nodes, which is not the same thing at all. To that extent the xml2
module documentation is at best imprecise and at worst plain wrong.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
