Re: xpath_table equivalent

Scott Bailey wrote:
>
> I agree that the syntax of XMLTABLE is odd. But not demonstrably worse 
> than xpathtable. 

That's not saying much. I dislike both. Why the SQL committee feels the 
need to invent arcane special case grammar rules is beyond me. I 
understand why the author of xpathtable designed it the way he did, but 
it's still ugly in my book.

As I said, with LATERAL we could produce a much cleaner functional 
equivalent.

> If we are going to exert effort on it, why not do it in a standards 
> compliant way? Otherwise I'd suggest a stop gap of just adding some 
> support functions to make it easier to extract a scalar value from a 
> node. Something like what I did here.
>
> http://scottrbailey.wordpress.com/2009/06/19/xml-parsing-postgres/

I think that's an orthogonal issue, really. There's probably a good case 
for such a function whether or not we do something like xpath_table.

>
> 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.)

cheers

andrew