Tom Lane wrote:
> Andrew Dunstan <andrew@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.
>>>
>
>
>> 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.
>
>
Well, I think that's going to be hard or impossible to avoid in the
general case. My suggestion was intended to give the user a much better
chance of avoiding it, however.
Arbitrary XML (or JSON or YAML or any artbitrarilly tree structured data
markup) doesn't map well to a rectangular structure, and this is always
likely to cause problems like this IMO.
I guess in the end the user could preprocess the XML with XSLT to remove
the irregularities before passing to to xpath_table.
We certainly need to put some warnings in the docs about it.
cheers
andrew
