Re: xpath not a good replacement for xpath_string

>>
>> 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.

That is sort of the point I was making. It just seems arcane, by the very
definition of arcane, within a SQL context. It is workable and it can be
used, but I don't think the change was designed to make writing queries
easier. It was designed to be more about "XPath" than SQL.

>
> It's also probably not terribly hard to produce a wrapper to do what
> you'd like.

No, it isn't but you haven't made the usage of XPath any easier in the
more general case.

>
> 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.

Well, the API is there, it is where, I guess, PostgreSQL is going, but I
think, philosophically, the API needs to see the XML contained within SQL
columns as being able to represent variable and optional columns in object
oriented environments easily. The harder it is to use a feature, the less
usable the feature is.

Do you disagree?

>
> cheers
>
> andrew
>
> --
> 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
>