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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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