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: 264855a00711220537s156c9926ya663cfa6cf819b3e@mail.gmail.com (view raw or flat)
Thread:
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.

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

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-2014 The PostgreSQL Global Development Group