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

Re: xpath_array with namespaces support

From: "Nikolay Samokhvalov" <samokhvalov(at)gmail(dot)com>
To: "Bruce Momjian" <bruce(at)momjian(dot)us>
Cc: "Peter Eisentraut" <peter_e(at)gmx(dot)net>, pgsql-patches(at)postgresql(dot)org
Subject: Re: xpath_array with namespaces support
Date: 2007-04-22 07:21:55
Message-ID: e431ff4c0704220021y72ef7778q957600c21162da68@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-patches
What's with this patch?
I do not see it in unapplied patches list, neither it was commited...
What we have now in CVS is not a good thing.

On 4/10/07, Nikolay Samokhvalov <samokhvalov(at)gmail(dot)com> wrote:
> Here is new version that adds following changes:
>   4. Function is now strict, per discussion.
>   5. Return empty array in case when XPath expression detects nothing
> (previously, NULL was returned in such case), per discussion.
>   6. (bugfix) Work with fragments with prologue: select xpath('/a',
> '<?xml version="1.0"?><a /><b />'); // now XML datum is always wrapped
> with dummy <x>...</x>, XML prologue simply goes away (if any).
>   7. Some cleanup.
>
> On 4/4/07, Nikolay Samokhvalov <nikolay(at)samokhvalov(dot)com> wrote:
> > The patch attached contains following changes:
> >    1. The function name xmlpath() is changed to xpath();
> >    2. Approach of passing of namepspace mappings to the function is changed:
> > now that array (the 3rd argument) should be a 2-dimentional array with the
> > length of the second axis = 2 (e.g., ARRAY[ARRAY['a1', 'http://a1'],
> > ARRAY['a2', 'http://a2'], ARRAY['a2', 'http://a2']]);
> >    3. Description of xpath() function in docs (I'm sorry for possible
> > mistakes in English and docbook formatting, please check it...)

-- 
Best regards,
Nikolay

In response to

Responses

pgsql-patches by date

Next:From: Bruce MomjianDate: 2007-04-22 13:26:20
Subject: Re: [COMMITTERS] pgsql: Some further performance tweaks for planning large inheritance
Previous:From: Tom LaneDate: 2007-04-21 23:21:10
Subject: Re: [HACKERS] parser dilemma

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