Re: remove contrib/xml2

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