In that case, if you are already tied to Oracle why not just use their tools rather than something like this? Oracle's tools will hopefully work in lock-step with their releases and there should be no support lag.
This looks neat, but why add another layer of lock-in to yet another vendor with the uncertainty that entails?
I thought that was a clear and honest question.
The remainder, the "piping" syntax, is pretty easy to implement (Takes about 30-40 lines of ruby on top of Arel, speaking from experience).
So then, is this just a matter of wrapping a library in a web page and calling it SAAS? Or am I just totally missing the point?
on Oracle:
http://docs.oracle.com/cd/E11882_01/server.112/e10592/statem...
on SQL Server: http://msdn.microsoft.com/en-us/library/ms175972.aspx
As useful as SQL is in so many ways, as a piece of language design it's a total bloody travesty. I'm delighted to see any movement towards a query language that keeps the nice declarative dataflow property that complex SQL queries can have, but provides better means of abstraction, and the possibility to write more intention-revealing code.
In Oracle's implementation WITH is more like a VIEW.
Edit: BTW, this is not an accident or oversight on the part of Postgres. This is in the spec!
I did quite a bit of SQL in my last job, and I can't think of a single case where I wish I had a pipeline operator. If I wanted to do something similar to the example on your homepage the simplest way is just to use subqueries.
Here's a rewrite of your query in T-SQL...
------------------------------------------------------
SELECT EMP.Country, EMP.LastName, EMP.FirstName, OD.OrderID, ORD.ShippedDate, OD.SaleAmount
FROM (SELECT TOP 10 T1.OrderID, T1.ORDSUM FROM (SELECT OrderID, SUM(UnitPrice * Quantity * (1 - Discount)) AS SaleAmount FROM "Order Details" GROUP BY OrderID) AS T1 ORDER BY T1.ORDSUM DESC) AS OD
LEFT JOIN Orders AS ORD ON OD.OrderID = ORD.OrderID
LEFT JOIN Employees AS EMP ON ORD.EmployeeID = EMP.EmployeeID
------------------------------------------------------
That's fairly concise, and was quick to bash out. I'd wager it could be made even smaller if I used LINQ instead of SQL. Perhaps your method has some advantages in other types of query? How do you see it?
Currently, all ORMs that I've seen try to mimic the declarative SQL syntax, which doesn't always look pretty.
Layers are just hiding things, and when you hide it, bad things happen.
But I don't have any real world experience writing software that actually ends up being used with different databases.
I may use all these abstractions, but really we just use Postgres or MySQL in the end.
In 99% of cases you don't need to write SQL in order to deliver business functionality. Just like we don't need to write low level machine code in 99% of cases.
One benefit a layer can add is the ability to optimize post compilation. Most of the fancy pants Hadoop libraries are doing this one way or another.
