[jameshart]

Not totally convinced by the ORDER BY obstacles that the author raises..

    table('test').project('a').orderBy('b')

> That's an error, because we can't order by a column that we just projected away. Right?

assumes that 'projection' completely eliminates part of the underlying relation, but why does that have to be the case?

If a relation includes 'selected fields' and 'hidden fields', and project just 'hides' the fields it doesn't project, while orderBy can operate on either projected or hidden fields, this ends up being perfectly sound.

Even the more complex example which is translated as follows:

   translate('select a+1 as c from test order by b,c')
   =>
   table('test').project('a','b').addColumn('a+1', as='c').orderBy('b','c').project('a')

would work fine as:

   table('test')                 // selected: [a, b, ...], hidden: []
      .addColumn('a+1', as='c')  // selected: [a, b, c, ...], hidden: []
      .project('c')              // selected: [c], hidden: [a, b, ...]
      .orderBy('b','c')          // selected: [c], hidden: [a, b, ...] 

(not sure why there's a .project('a') on the end of their version)

Which is a reasonably local, algebraic transformation.