From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Nikolay Samokhvalov <samokhvalov(at)gmail(dot)com> |
Subject: | Re: xpath processing brain dead |
Date: | 2009-02-26 16:37:57 |
Message-ID: | 49A6C565.20803@gmx.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Dunstan wrote:
> For fear of passing an ill formed fragment of xml to the processor, we
> strip the xml declaration if any and surround what's left with '<x>" and
> '</x>' and prepend '/x' to the supposed xpath. This is just horrible. It
> will break for every xpath expression that doesn't begin with a '/' and
> probably for many that do.
>
> This whole thing is a mess, and I suspect the only fix for now is to
> undo all the mangling of both the xml and the xpath expression. If the
> programmer passes an ill formed piece of xml to the processor that is
> their lookout, but I think we should ensure that we give back correct
> results on well formed input.
It's not about ill-formed pieces, it is about (well-formed) content
fragments that are not full documents (exactly one root element).
libxml2 doesn't support xpath on content fragments.
The tradeoff here is either supporting no xpath at all on content
fragments or supporting some xpath on both kinds of xml data. Whoever
made the initial implementation of this (Nikolay, Cc) decided for the
latter, but I can't say I'm happy with it either. I'd be OK with
changing it, but I haven't had time to get to it, unfortunately.
See also <http://wiki.postgresql.org/wiki/XPath_Todo#XPath>.
From | Date | Subject | |
---|---|---|---|
Next Message | Teodor Sigaev | 2009-02-26 16:41:42 | Re: GIN fast insert |
Previous Message | Bruce Momjian | 2009-02-26 16:35:37 | Re: Updates of SE-PostgreSQL 8.4devel patches (r1608) |