Patch applied.

Please provide a documentation addition. Thanks.

---------------------------------------------------------------------------


Nikolay Samokhvalov wrote:
> On 3/4/07, Nikolay Samokhvalov <nikolay@samokhvalov.com> wrote:
> > I'll fix these issues and extend the patch with resgression tests and
> > docs for xpath_array(). I'll resubmit it very soon.
>
> Here is a new version of the patch. I didn't change any part of docs yet.
> Since there were no objections I've changed the name of the function
> to xmlpath().
>
> --
> Best regards,
> Nikolay

[ Attachment, skipping... ]

>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Bruce Momjian wrote:
> Patch applied.

This code seems to think that if an xml datum starts with "<?xml" it's a
document. That is completely bogus.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Am Mittwoch, 4. April 2007 14:42 schrieb Nikolay Samokhvalov:
> Maybe it's worth to start keeping additional information in xml datum (i.e.
> bit IS_DOCUMENT and, what is more important for xpath() function, a bit
> indicating that XML value has only one root and can be considered as a tree
> => there is no need to wrap with <x> .. </x>). But this change requires
> additional time to design xml datum structure and to rework the code
> (macros, I/O functions...).

To determine if an XML datum is a document, call xml_is_document(). The
implementation of that function is probably not the best possible one, but
what the xpath() code does it totally wrong nevertheless.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Am Mittwoch, 4. April 2007 15:20 schrieb Nikolay Samokhvalov:
> > To determine if an XML datum is a document, call xml_is_document(). The
> > implementation of that function is probably not the best possible one,
> > but what the xpath() code does it totally wrong nevertheless.
>
> You are proposing 2-3 (depends on the case) parsing times for the one XML
> value instead of current 1-2

I know it's bad, and something like adding a bit (byte) to mark this in the
value would be good, but that doesn't change the fact that

(xmlStrncmp((xmlChar *) VARDATA(data), (xmlChar *) "<?xml", 5) == 0)

is not a valid method to tell apart a document from a fragment. Proof:

pei=# select xml '<?xml version="1.0"?><foo>bar</foo>' IS DOCUMENT;
?column?
----------
t
(1 row)

pei=# select xml '<?xml version="1.0"?><foo>bar</foo><foo>bar</foo>' IS
DOCUMENT;
?column?
----------
f
(1 row)

pei=# select xml '<foo>bar</foo>' IS DOCUMENT;
?column?
----------
t
(1 row)

pei=# select xml '<foo>bar</foo><foo>bar</foo>' IS DOCUMENT;
?column?
----------
f
(1 row)

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

On 4/4/07, Nikolay Samokhvalov <nikolay@samokhvalov.com> wrote:
>
>
> So, choosing between two inefficient approaches:
> 1. mine, which in some cases use dummy element wrapping, that we could
> escape;
> 2. proposed by you, which leads to +1 parsing.
> ... I'd definitely choose the first one.
>

I'd make it a bit more clear.

We have different cases for XML value as input of xpath():
a. document with prolog ('<?xml...')
b. document w/o prolog (value that can be represented as a tree -- i.e. we
have one root)
c. fragment with one root element (can be represented as a tree)
d. fragment w/o root element (cannot be represented as a tree, e.g.
'bla'::xml)

So, the current implementation works w/o wrapping in case a) and use
wrapping for cases b)-d).
But we _need_ wrapping _only_ in case d) -- so there is space for
optimization (I would keep bit "this value is not a tree" in the value
itself).

--
Best regards,
Nikolay