Re: xpath not a good replacement for xpath_string

> 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';