On Nov 22, 2007 5:42 AM, Nikolay Samokhvalov <samokhvalov@gmail.com> wrote:
> On Nov 21, 2007 8:42 PM, Sean Davis <sdavis2@mail.nih.gov> wrote:
> > Thanks, Pavel for the reply. However, I looked a bit more and it
> > appears that xpath always returns an xml array in 8.3b2.
> >
> > annodb=# \df xpath;
> > List of functions
> > Schema | Name | Result data type | Argument data types
> > ------------+-------+------------------+---------------------
> > pg_catalog | xpath | xml[] | text, xml
> > pg_catalog | xpath | xml[] | text, xml, text[]
> > (2 rows)
> >
> > So, there is not a way to force a single element to be returned as far
> > as I can see. I did an equivalent example to the one you suggested:
>
> The xpath() function added to 8.3 is generic function, so it really
> returns xml[] always. That was the main aim -- to add the generic
> function.
>
> You can easily create any wrapper to meet your needs. E.g., smth like
> xpath_first() that always returns only the first xml chunk, or
> xpath_single() that performs concatenation of all xml chunks and
> returns single xml.
>
> Anyway, in both cases you break significantly from the general XML
> semantics -- that's why such stuff is not implemented by default. BTW,
> maybe some convenient wrappers will be added to Postgres in the
> future, but surely this should be done only after good volume of
> practical experience is collected.
Nikolay,
I agree almost fully with these thoughts. I have not used xpath much,
so I don't know what the default behavior is (in terms of a spec). I
would suggest that the default behavior in postgres should match
whatever a spec is. That said, the utility of the current
implementation is fantastic, especially when combined with the ability
to produce custom functions when necessary.
Thanks again,
Sean
