Andrew Dunstan <and...@dunslane.net> writes:
> Tom Lane wrote:
>> ... The reason for that behavior is that xpath_table runs through
>> the XPATH_NODESET results generated by the various XPaths and dumps the
>> k'th one of each into the k'th output row generated for the current
>> input row.
> Damn that's ugly.
Yup :-(
> ISTM the missing piece is really in our API. We need to be able to
> specify a nodeset to iterate over, and then for each node take the first
> value produced by each xpath expression. So the example above would look
> something like:
> SELECT * FROM xpath_table('id', 't', 'xpath_test',
> '/rowlist/row', '@a|@b', 'true') as t(id int4, a text, b text);
Hm. It seems like that still leaves you open to the possibility of
out-of-sync results. If you consider the current behavior as what
you'd get with an empty root nodeset spec, then restricting it to
produce only the first output row doesn't help at all -- it would still
associate "1" with "oops". In general if the nodeset spec doesn't
select a unique subnode then you're at risk of bogus answers.
Maybe that could be defined as user error but it sure seems like it
would be error-prone to use.
> Maybe we could approximate that with the current API by factoring out
> the common root of the xpath expressions, but that's likely to be
> extremely fragile and error prone, and we've already got bad experience
> of trying to be too cute with xpath expressions.
Agreed, we do not want to be doing textual manipulations of XPaths,
which is what burnt us before. But does libxml2 offer any more
abstract path representation we could work on?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
