Skip site navigation (1) Skip section navigation (2)

Re: remove contrib/xml2

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: remove contrib/xml2
Date: 2010-03-01 13:53:37
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)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.



In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2010-03-01 15:01:09
Subject: Re: Re: pgsql: add EPERM to the list of return codes to expect from opening
Previous:From: Magnus HaganderDate: 2010-03-01 13:37:00
Subject: Re: Re: pgsql: add EPERM to the list of return codes to expect from opening

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group