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

Re: XMLATTRIBUTES vs. values of type XML

From: Florian Pflug <fgp(at)phlo(dot)org>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: XMLATTRIBUTES vs. values of type XML
Date: 2011-07-27 17:37:31
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Jul27, 2011, at 16:18 , Peter Eisentraut wrote:
> On tis, 2011-07-26 at 22:44 +0200, Florian Pflug wrote:
>> While reviewing the (now applied) XPATH escaping patches, Radoslaw
>> found one
>> case where the previous failure of XPATH to escape its return value
>> was offset
>> by XMLATTRIBUTES insistence to escape all input values, even if
>> they're
>> already of type XML.
>> To wit, if you do
>> you get
>>     xmlelement     
>> --------------------
>> <t a="&amp;amp;"/> 
> Per SQL standard, the attribute values may not be of type XML, so maybe
> we should just prohibit it.

We probably should have, but I think it's too late for that. I don't
believe I'm the only one who uses XPATH results as attribute values,
and we'd severely break that use-case.

You might say the same thing about my proposal, of course, but I believe
the risk is much smaller there. Applications would only break if they
  (a) Pass XML from a source other than a XPath expression selecting
      a text or attribute and
  (b) actually want double-escaping to occur.

As a data point, I've written an application with makes heavy use of
our XML infrastructure over the last few months (as you might have guessed
from the stream of patches ;-)). That application would be pretty much
untroubled by the changes to XMLATTRIBUTES I proposed, but would be
severely broken if we rejected values of type XML all together.

best regards,
Florian Pflug

In response to


pgsql-hackers by date

Next:From: Florian PflugDate: 2011-07-27 17:57:44
Subject: Re: PQescapeByteaConn - returns wrong string for PG9.1 Beta3
Previous:From: Robert HaasDate: 2011-07-27 17:30:47
Subject: Re: sinval synchronization considered harmful

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