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

Review of patch Bugfix for XPATH() if expression returns a scalar value

From: Radosław Smogura <rsmogura(at)softperience(dot)eu>
To: PG Hackers <pgsql-hackers(at)postgresql(dot)org>, Florian Pflug <fgp(at)phlo(dot)org>
Subject: Review of patch Bugfix for XPATH() if expression returns a scalar value
Date: 2011-06-29 17:57:03
Message-ID: (view raw or whole thread)
Lists: pgsql-hackers
This is review of patch
"Bugfix for XPATH() if expression returns a scalar value"

Patch applies cleanly, and compiles cleanly too, I didn't checked tests.

	Form discussion about patch, and referenced thread in this patch, if I 
understand good such functionality is desired.

	This patch, I think, gives good approach for dealing with scalar values, 
and, as well converting value to it's string representation is good too 
(according to current support for xml), with one exception detailed below.

	In this patch submitter, similarly to, added 
functionality for XML-escaping of some kind of values (I think only string 
scalars are escaped), which is not-natural and may lead to double escaping in 
some situation, example query may be:

(XPATH('namespace-uri(/*)', x))[1] AS namespace FROM (VALUES (XMLELEMENT(name 
"root", XMLATTRIBUTES('<n' AS xmlns, '<v' AS value),'<t'))) v(x)) as foo;

 <root sth="&amp;lt;n"/>
	It's clearly visible that value from attribute is "&lt;n", not "<". Every 
parser will read this as "&lt;n" which is not-natural and will require form 
consumer/developer to de-escape this on his side - roughly speaking this will 
be reported as serious bug.
	I didn't found good reasons why XML-escaping should be included, submitter 
wrote about inserting this to xml column and possibility of data damage, but 
didn't give an example. Such example is desired.

I vote +1 for this patch if escaping will be removed.

Radoslaw Smogura


pgsql-hackers by date

Next:From: Robert HaasDate: 2011-06-29 18:11:34
Subject: Re: time-delayed standbys
Previous:From: Simon RiggsDate: 2011-06-29 17:50:22
Subject: Re: time-delayed standbys

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