Re: xpath question

["Sean Davis" <sdavis2(at)mail(dot)nih(dot)gov>]

On Nov 22, 2007 5:42 AM, Nikolay Samokhvalov <samokhvalov(at)gmail(dot)com> wrote:
> On Nov 21, 2007 8:42 PM, Sean Davis <sdavis2(at)mail(dot)nih(dot)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