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: 4A70705E.3070006@dunslane.net (view raw or flat)
Thread:
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.

cheers

andrew

In response to

Responses

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-2014 The PostgreSQL Global Development Group