Skip site navigation (1) Skip section navigation (2)

Re: xpath question

From: "Sean Davis" <sdavis2(at)mail(dot)nih(dot)gov>
To: "Nikolay Samokhvalov" <samokhvalov(at)gmail(dot)com>
Cc: pgsql-novice(at)postgresql(dot)org
Subject: Re: xpath question
Date: 2007-11-22 13:37:20
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-novice
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.


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,

In response to

pgsql-novice by date

Next:From: Mag GamDate: 2007-11-22 16:41:23
Subject: On-line backup and point-in-time recovery (PITR), and human error
Previous:From: Nikolay SamokhvalovDate: 2007-11-22 10:42:17
Subject: Re: xpath question

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group