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

Re: xpath not a good replacement for xpath_string

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: pgsql(at)mohawksoft(dot)com
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, Kevin Grittner <kevin(dot)grittner(at)wicourts(dot)gov>
Subject: Re: xpath not a good replacement for xpath_string
Date: 2009-07-29 15:53:02
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

pgsql(at)mohawksoft(dot)com wrote:
>> On Tuesday 28 July 2009 23:30:23 pgsql(at)mohawksoft(dot)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.



In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2009-07-29 16:15:42
Subject: Re: date_part()/EXTRACT(second) behaviour with time data type
Previous:From: Pavel StehuleDate: 2009-07-29 15:46:10
Subject: Re: WIP: to_char, support for EEEE format

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