From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Scott Bailey <artacus(at)comcast(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: xpath_table equivalent |
Date: | 2009-11-21 16:34:29 |
Message-ID: | 4B081695.6010604@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2009-11-21 16:41:41 | Re: Proposal: USING clause for DO statement |
Previous Message | Gurjeet Singh | 2009-11-21 16:27:16 | Re: DEFAULT of domain ignored in plpgsql (8.4.1) |