Andrew Dunstan wrote:
Hannu Krosing wrote:
Is it just that in you _can't_ use Xpath on fragments, and you _need_ to
pass full documents to Xpath ?
At least this is my reading of Xpath standard.
I think that's possibly overstating it., unless I have missed
something (W3 standards are
On Mar 20, 2009, at 8:56 AM, Andrew Dunstan wrote:
Andrew Dunstan wrote:
A / at the beginning of a path expression is an abbreviation for
the initial step fn:root(self::node()) treat as document-node()/
(however, if the / is the entire path expression, the trailing
/
is omitted from
Andrew Dunstan wrote:
can you point me at any call in libxml2 which will evaluate an xpath
expression in the context of a nodeset instead of a document? Quite
apart from anything else, xpath requires there to be a (single) context
node (see http://www.w3.org/TR/xpath20/#context ). For a doc,
On Sun, 2009-03-01 at 18:22 -0500, Andrew Dunstan wrote:
I think the XML type needs to conform to the SQL/XML spec. However, we
are trying to apply XPath, which has a different data model, to that
type - hence the impedance mismatch.
I think that the best we can do (for 8.4, having fixed
Peter Eisentraut wrote:
Andrew Dunstan wrote:
can you point me at any call in libxml2 which will evaluate an xpath
expression in the context of a nodeset instead of a document? Quite
apart from anything else, xpath requires there to be a (single)
context node (see
Simon Riggs wrote:
On Sun, 2009-03-01 at 18:22 -0500, Andrew Dunstan wrote:
I think the XML type needs to conform to the SQL/XML spec. However, we
are trying to apply XPath, which has a different data model, to that
type - hence the impedance mismatch.
I think that the best we can do
On Mon, 2009-03-02 at 07:54 -0500, Andrew Dunstan wrote:
Simon Riggs wrote:
On Sun, 2009-03-01 at 18:22 -0500, Andrew Dunstan wrote:
I think the XML type needs to conform to the SQL/XML spec. However, we
are trying to apply XPath, which has a different data model, to that
type -
Hannu Krosing wrote:
Is it just that in you _can't_ use Xpath on fragments, and you _need_ to
pass full documents to Xpath ?
At least this is my reading of Xpath standard.
It is easy to read the XPath standard that way, because the concept of
fragments is not defined outside of SQL/XML,
Hannu Krosing wrote:
Is it just that in you _can't_ use Xpath on fragments, and you _need_ to
pass full documents to Xpath ?
At least this is my reading of Xpath standard.
I think that's possibly overstating it., unless I have missed something
(W3 standards are sometimes not much
On Mon, 2009-03-02 at 15:25 +0200, Peter Eisentraut wrote:
Hannu Krosing wrote:
Is it just that in you _can't_ use Xpath on fragments, and you _need_ to
pass full documents to Xpath ?
At least this is my reading of Xpath standard.
It is easy to read the XPath standard that way,
Hannu Krosing wrote:
Some of the functions, including some specified in the standard, produce
fragments. That's why we have the 'IS DOCUMENT' test.
But then you could use xmlfragments as the functions return type, no ?
Does tha standard require that the same field type must store both
On Sun, 2009-03-01 at 10:13 -0500, Andrew Dunstan wrote:
Hannu Krosing wrote:
Some of the functions, including some specified in the standard, produce
fragments. That's why we have the 'IS DOCUMENT' test.
But then you could use xmlfragments as the functions return type, no ?
Hannu Krosing wrote:
On Sun, 2009-03-01 at 10:13 -0500, Andrew Dunstan wrote:
Hannu Krosing wrote:
Some of the functions, including some specified in the standard, produce
fragments. That's why we have the 'IS DOCUMENT' test.
But then you could use xmlfragments as the
sigh.. I got curious. :P
On Feb 27, 2009, at 7:19 PM, James Pye wrote:
Well, that or force the user to call it explicitly.
Attached is the patch that I used to get the results below..
This is just a proof of concept, so it's quite lacking. Notably, it
doesn't even try to identify
James Pye wrote:
sigh.. I got curious. :P
On Feb 27, 2009, at 7:19 PM, James Pye wrote:
Well, that or force the user to call it explicitly.
Attached is the patch that I used to get the results below..
This is just a proof of concept, so it's quite lacking. Notably, it
doesn't even try to
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:
I wrote:
I'll test again on some longer fragments since you don't seem convinced.
I set up a test with a much larger XML fragment - over 1Mb - basically
it's the English source of the SVN Turtle book.
The result is that the extra parsing cost is still pretty much unmeasurable:
On Fri, 2009-02-27 at 22:55 -0500, Andrew Dunstan wrote:
Hannu Krosing wrote:
Some of the functions, including some specified in the standard, produce
fragments. That's why we have the 'IS DOCUMENT' test.
But then you could use xmlfragments as the functions return
On Thu, 2009-02-26 at 13:51 -0500, Robert Haas wrote:
What I have proposed for 8.3 should not break a single case that currently
behaves usefully. If anyone has a counter-example please show it.
What I have proposed for 8.4 possibly would break current useful behaviour
(FSVO useful), but
Hannu Krosing wrote:
On Thu, 2009-02-26 at 13:51 -0500, Robert Haas wrote:
What I have proposed for 8.3 should not break a single case that currently
behaves usefully. If anyone has a counter-example please show it.
What I have proposed for 8.4 possibly would break current useful
Andrew Dunstan wrote:
Tom Lane wrote:
Hmm, does this proposal require adding a test of well-formed-ness to
a code path that doesn't currently have one? If so, is that likely
to contribute any noticeable slowdown?
I can't offhand see an objection to this other than possible performance
Andrew Dunstan and...@dunslane.net writes:
I'll do some tests to see what the cost of extra xml parsing might be.
The extra cost appears to be fairly negligible.
Uh, you didn't actually show a comparison of before and after?
What it looks like to me is that this approach is free or nearly so
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
I'll do some tests to see what the cost of extra xml parsing might be.
The extra cost appears to be fairly negligible.
Uh, you didn't actually show a comparison of before and after?
What it looks like to me is
On Fri, 2009-02-27 at 16:37 -0500, Andrew Dunstan wrote:
Hannu Krosing wrote:
On Thu, 2009-02-26 at 13:51 -0500, Robert Haas wrote:
What I have proposed for 8.3 should not break a single case that currently
behaves usefully. If anyone has a counter-example please show it.
What I
On Feb 26, 2009, at 7:03 PM, Andrew Dunstan wrote:
can you point me at any call in libxml2 which will evaluate an xpath
expression in the context of a nodeset instead of a document?
No, I can't. node-sets are XPath objects not xmlNode objects, so I
don't think it would be as simple as
Hannu Krosing wrote:
Some of the functions, including some specified in the standard, produce
fragments. That's why we have the 'IS DOCUMENT' test.
But then you could use xmlfragments as the functions return type, no ?
Not in the case of xpath, no.
There is a very
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
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.
I seem to
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
Peter Eisentraut wrote:
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
Andrew Dunstan and...@dunslane.net writes:
I don't think it is our responsibility to remedy the deficiencies of
libxml2, especially if it involves breaking the processing of valid
xpath expressions on well formed XML.
If someone can come up with a correct scheme for handling fragments, I'm
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
I don't think it is our responsibility to remedy the deficiencies of
libxml2, especially if it involves breaking the processing of valid
xpath expressions on well formed XML.
If someone can come up with a correct scheme
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
I'm okay with removing this for 8.4, but I think it's too late to
change the behavior of 8.3.
It's never too late to fix a bug.
When the proposed fix involves breaking cases that used to behave
usefully, you need a much stronger
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
I'm okay with removing this for 8.4, but I think it's too late to
change the behavior of 8.3.
It's never too late to fix a bug.
When the proposed fix involves breaking cases that used to
What I have proposed for 8.3 should not break a single case that currently
behaves usefully. If anyone has a counter-example please show it.
What I have proposed for 8.4 possibly would break current useful behaviour
(FSVO useful), but should be done anyway on correctness grounds.
I dunno,
Robert Haas wrote:
What I have proposed for 8.3 should not break a single case that currently
behaves usefully. If anyone has a counter-example please show it.
What I have proposed for 8.4 possibly would break current useful behaviour
(FSVO useful), but should be done anyway on correctness
On Thu, Feb 26, 2009 at 3:18 PM, Andrew Dunstan and...@dunslane.net wrote:
I dunno, aren't XML document fragments sort of a pretty common case?
They are. So what? How does that contradict either of the statements made
above?
Programmers using libxml2 are used to handling this problem. Why
On Thu, 2009-02-26 at 15:37 -0500, Robert Haas wrote:
Mine is very light indeed. But the change you're proposing seems like
it could CONCEIVABLY break a working application that counts on
PostgreSQL's particular flavor of misbehavior,
That is what release notes are for.
Joshua D. Drake
--
Robert Haas wrote:
But the change you're proposing seems like
it could CONCEIVABLY break a working application that counts on
PostgreSQL's particular flavor of misbehavior, and therefore it seems
questionable to put that into a stable branch. The fact that the
application perhaps should not
I wrote:
Second, I propose that, in the remaining cases, where we do mangle the
XML, if the xpath expression does not begin with a '/', instead of
prepending it with '/x/, which can not possibly be correct under any
circumstance, we prepend it with '/x//' which has some possibility of
Andrew Dunstan and...@dunslane.net writes:
First, I propose that we abandon this mangling, if, and only if, the xml
is in fact a well formed XML document. Since the whole point of the
mangling is to handle situations where the XML is not a well formed
document, that seems fairly
On Thu, Feb 26, 2009 at 3:54 PM, Andrew Dunstan and...@dunslane.net wrote:
Robert Haas wrote:
But the change you're proposing seems like
it could CONCEIVABLY break a working application that counts on
PostgreSQL's particular flavor of misbehavior, and therefore it seems
questionable to put
On Feb 26, 2009, at 9:37 AM, Peter Eisentraut wrote:
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.
exslt:node-set() to the rescue? Or is
James Pye wrote:
On Feb 26, 2009, at 9:37 AM, Peter Eisentraut wrote:
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.
exslt:node-set() to the rescue? Or
On Feb 26, 2009, at 5:41 PM, Andrew Dunstan wrote:
http://www.exslt.org/exsl/functions/node-set/index.html
A node-set isn't a document.
yes.. :)
I guess what I'm saying is that if:
tinman=# SELECT XML'foo/bar/';
xml
--
foo/bar/
(1 row)
is considered to be valid per
James Pye wrote:
On Feb 26, 2009, at 5:41 PM, Andrew Dunstan wrote:
http://www.exslt.org/exsl/functions/node-set/index.html
A node-set isn't a document.
yes.. :)
I guess what I'm saying is that if:
tinman=# SELECT XML'foo/bar/';
xml
--
foo/bar/
(1 row)
is considered
Tom Lane wrote:
Hmm, does this proposal require adding a test of well-formed-ness to
a code path that doesn't currently have one? If so, is that likely
to contribute any noticeable slowdown?
I can't offhand see an objection to this other than possible performance
impact.
Andrew Gierth was just pointing out to me how badly broken our XPath
processing is.
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
Andrew Dunstan and...@dunslane.net writes:
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.
I seem to recall having complained about
48 matches
Mail list logo
