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

Re: xpath not a good replacement for xpath_string

From: pgsql(at)mohawksoft(dot)com
To: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: "Andrew Dunstan" <andrew(at)dunslane(dot)net>, pgsql(at)mohawksoft(dot)com, "PostgreSQL" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: xpath not a good replacement for xpath_string
Date: 2009-07-28 20:30:23
Message-ID: 933883f56ddd4abada4b1cb430cc33b1.squirrel@mail.mohawksoft.com (view raw or flat)
Thread:
Lists: pgsql-hackers
> Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>
>> in fact the desired functionality is present [...] You just need to
>> use the text() function to get the contents of the node, and an
>> array subscript to pull it out of the result array.
>
> I just took a quick look, and that didn't jump out at me from the
> documentation.  Perhaps there should be an example or two of how to
> get the equivalent functionality through the newer standard API, for
> those looking to migrate?
>
> Would it make sense to supply convenience SQL functions which map
> some of the old API to the new?

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.

Another thing that is troubling is that more exotic types do not seem to
be supported at all. For instance, in my example I used uuid, and if one
substitutes "uuid()" for "text()" that doesn't work.

The API is less intuitive than the previous incarnation and is, indeed,
more difficult to use.



>
> -Kevin
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>


In response to

Responses

pgsql-hackers by date

Next:From: Pavel StehuleDate: 2009-07-28 20:53:08
Subject: plpgsql: support identif%TYPE[], (from ToDo)
Previous:From: Kevin GrittnerDate: 2009-07-28 20:29:16
Subject: Re: xpath not a good replacement for xpath_string

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