Re: xpath_table equivalent - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: xpath_table equivalent
Date
Msg-id 4B081695.6010604@dunslane.net
Whole thread Raw
In response to Re: xpath_table equivalent  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers

I wrote:
>>
>> The nice thing about XMLTABLE is that it adds xquery support. I think 
>> the majority of xquery engines seem to be written in Java. XQuilla is 
>> C++. I'm not sure if our licensing is compatible, but it I would love 
>> the irony of using Berkeley DB XML (formerly Sleepycat) now that its 
>> owned by Oracle.
>>
>>
>
> XQuery is a whole other question. Adding another library dependency is 
> something we try to avoid. Zorba <http://www.zorba-xquery.com/> might 
> work, but it appears to have its own impressive list of dependencies 
> (why does it require both libxml2 and xerces-c? That looks a bit 
> redundant.)
>
> Even if we did implement XMLTABLE, I think I'd probably be inclined to 
> start by limiting it to plain XPath, without the FLWOR stuff. I think 
> that would satisfy the vast majority of needs, although you might feel 
> differently. (Do a Google for XMLTABLE - every example I found uses 
> plain XPath expressions.)
>
>

I did look at this a bit further. Sadly, XQilla's XSLT support is stated 
to be of alpha quality, and missing some quite necessary features (e.g. 
xsl:output). That pretty much rules out for now Xerces-C+XQilla as an 
alternative xml stack to libxml2+libxslt, ISTM.

cheers

andrew



pgsql-hackers by date:

Previous
From: Gurjeet Singh
Date:
Subject: Re: DEFAULT of domain ignored in plpgsql (8.4.1)
Next
From: Pavel Stehule
Date:
Subject: Re: Proposal: USING clause for DO statement