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
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 s
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
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 more
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, and
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 t
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 (f
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 http://www.w3.org/TR/xpath2
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 fi
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, we
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 f
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
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
d
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
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:
regres
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
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
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 well-forme
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 compl
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 modify
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
Tom Lane wrote:
Andrew Dunstan 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
Andrew Dunstan 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 for
well-formed do
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
impa
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" behavio
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 "
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.
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'';
xml
--
(1 row)
is considered to be valid per *S
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'';
xml
--
(1 row)
is considered to be valid per *SQL-XML*, then it sho
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 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 that/equivalent
On Thu, Feb 26, 2009 at 3:54 PM, Andrew Dunstan 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 that into a s
Andrew Dunstan 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 straight-forward. If this c
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
givi
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 ha
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
On Thu, Feb 26, 2009 at 3:18 PM, Andrew Dunstan 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 must
> postgres
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
> 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 d
Tom Lane wrote:
Andrew Dunstan 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 n
Andrew Dunstan 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 argument than that
Tom Lane wrote:
Andrew Dunstan 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 fragmen
Andrew Dunstan 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
> all ears, but
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
'" and '' and prepend '/x' to the supposed xpath. This is just
horrible. It will break for every xpath expressio
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 '" and
'' and prepend '/x' to the supposed xpath. This is just horrible. It
will break for every xpath expression that doesn't begin with a
Tom Lane wrote:
Andrew Dunstan 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 '" and
'' and prepend '/x' to the supposed xpath. This is just horrible.
I seem to recall having complained a
Andrew Dunstan 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 '" and
> '' and prepend '/x' to the supposed xpath. This is just horrible.
I seem to recall having complained about that at the time,
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 '" and
'' and prepend '/x' to the supposed xpath. This is just horrible. I
48 matches
Mail list logo
