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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Mag Gam | 2007-11-22 16:41:23 | On-line backup and point-in-time recovery (PITR), and human error |
Previous Message | Nikolay Samokhvalov | 2007-11-22 10:42:17 | Re: xpath question |