Re: xpath not a good replacement for xpath_string - Mailing list pgsql-hackers

From pgsql@mohawksoft.com
Subject Re: xpath not a good replacement for xpath_string
Date
Msg-id 933883f56ddd4abada4b1cb430cc33b1.squirrel@mail.mohawksoft.com
Whole thread Raw
In response to Re: xpath not a good replacement for xpath_string  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses Re: xpath not a good replacement for xpath_string
Re: xpath not a good replacement for xpath_string
Re: xpath not a good replacement for xpath_string
List pgsql-hackers
> Andrew Dunstan <andrew@dunslane.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@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>



pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: xpath not a good replacement for xpath_string
Next
From: Pavel Stehule
Date:
Subject: plpgsql: support identif%TYPE[], (from ToDo)