Re: xpath processing brain dead

From: James Pye <lists(at)jwp(dot)name>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Nikolay Samokhvalov <samokhvalov(at)gmail(dot)com>
Subject: Re: xpath processing brain dead
Date: 2009-02-28 18:12:30
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Feb 28, 2009, at 7:53 AM, Andrew Dunstan wrote:
> This is entirely out of the question for 8.3, as it's a significant
> change of behaviour.

Yep. Even with implicit prefixing, the semantics are very different.

What got me thinking about it was this:

If it's desirable to avoid prefixing, what options remain?

(At least I find it desirable to avoid prefixing =)

> I'd also want to see this usage blessed by some xpath guru ... I'm
> not sure it meets the standard's requirements, but I could be wrong.

Oh, the context node question you raised? I think it would be easy to
expect that the standard is expecting a well-formed document to query
against in the first place, so I *do* think it's a very valid concern.

Curious, if we constructed an actual document fragment node from the
node list and set it as the document's root, would that be enough to
satisfy any requirements? It does appear to talk about nodes quite

In the current case, we're shaving the corners of the square peg so it
will fit in the round hole. In fragment()'s case, it seems we would be
trying to circumvent the round hole altogether..

I don't really like either way. :P

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2009-02-28 18:33:05 Re: xpath processing brain dead
Previous Message Tom Lane 2009-02-28 17:20:04 encoding conversion functions versus zero-length inputs