Re: xpath processing brain dead

Поиск
Список
Период
Сортировка
От James Pye
Тема Re: xpath processing brain dead
Дата
Msg-id 07085C3D-6310-472F-8973-FF72E5363962@jwp.name
обсуждение исходный текст
Ответ на Re: xpath processing brain dead  (Andrew Dunstan <andrew@dunslane.net>)
Список 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:
 http://archives.postgresql.org/pgsql-bugs/2008-07/msg00058.php

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.

http://www.w3.org/TR/xpath
http://www.w3.org/TR/xpath#data-model
http://www.w3.org/TR/xpath#infoset

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  
generally.


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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: encoding conversion functions versus zero-length inputs
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: xpath processing brain dead