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: | 4B8BC6E1.5060405@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-03-01 15:01:09 | Re: Re: pgsql: add EPERM to the list of return codes to expect from opening |
Previous Message | Magnus Hagander | 2010-03-01 13:37:00 | Re: Re: pgsql: add EPERM to the list of return codes to expect from opening |