> 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'; -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
