Thread: Re: [PATCHES] xpath_array with namespaces support

What about it? W/o this not large patch XML functionality in 8.3 will be weak...
Will it be accepted?

On 3/5/07, Nikolay Samokhvalov <samokhvalov@gmail.com> wrote:
> On 3/4/07, Nikolay Samokhvalov <nikolay@samokhvalov.com> wrote:
> > I'll fix these issues and extend the patch with resgression tests and
> > docs for xpath_array(). I'll resubmit it very soon.
>
> Here is a new version of the patch. I didn't change any part of docs yet.
> Since there were no objections I've changed the name of the function
> to xmlpath().
>


--
Best regards,
Nikolay

Nikolay Samokhvalov wrote:
> What about it? W/o this not large patch XML functionality in 8.3 will
> be weak...
> Will it be accepted?
>
>
In principle I am in favor of the patch.

Would it be better to use some more unlikely name for the dummy root
element used to process fragments than <x> ?

Perhaps even something in a special namespace?

cheers

andrew

Nikolay Samokhvalov wrote:
> On 3/17/07, Andrew Dunstan <andrew@dunslane.net> wrote:
>> In principle I am in favor of the patch.
>>
>> Would it be better to use some more unlikely name for the dummy root
>> element used to process fragments than <x> ?
>>
>> Perhaps even something in a special namespace?
>>
>
> I did think about it, but I didn't find any difficulties with simple
> <x>...</x>. The thing is that regardless the element name we have
> corresponding shift in XPath epression -- so, there cannot be any
> problem from my point of view... But maybe I don't see something and
> it's better to avoid _possible_ problem. It depends on PostgreSQL code
> style itself -- what is the best approach in such cases? To avoid
> unknown possible difficulties or to be clear?
>

If you are sure that it won't cause a problem then I think it's ok to
leave it, as long as there is a comment in the code that says why we are
sure it's ok.

cheers

andrew

On 3/17/07, Andrew Dunstan <andrew@dunslane.net> wrote:
> In principle I am in favor of the patch.
>
> Would it be better to use some more unlikely name for the dummy root
> element used to process fragments than <x> ?
>
> Perhaps even something in a special namespace?
>

I did think about it, but I didn't find any difficulties with simple
<x>...</x>. The thing is that regardless the element name we have
corresponding shift in XPath epression -- so, there cannot be any
problem from my point of view... But maybe I don't see something and
it's better to avoid _possible_ problem. It depends on PostgreSQL code
style itself -- what is the best approach in such cases? To avoid
unknown possible difficulties or to be clear?

-- 
Best regards,
Nikolay

Andrew Dunstan wrote:
> Would it be better to use some more unlikely name for the dummy root
> element used to process fragments than <x> ?

Why do we even need to support xpath on fragments?

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Am Mittwoch, 4. April 2007 14:43 schrieb Nikolay Samokhvalov:
> > Why do we even need to support xpath on fragments?
>
> Why not? I find it useful and convenient.

Well, rather than inventing bogus root wrapper elements, why not let users
call xmlelement() to produce the wrapper element themselves?

--
Peter Eisentraut
http://developer.postgresql.org/~petere/