planner: Is now table aware (#104)
Even though the planner only deals with one real table (subqueries do
not count) it's important that internally is treats all columns with
respect to the table they belong to. This allows for multiple tables in
the future (JOINs, etc).
This was a lot more involved that I thought it would be and has led to
adding a bunch of new hacks and complexity to the planner. At this point
we need to start really thinking about rewriting the planner soon.
Some unavoidable side affects (but actually all good) from this
refactoring:
1. The EXPLAIN plan now shows the table name in expressions, such as
"FOO.ID" instead of just "ID". This is slightly more verbose but
ultimately better overall.
2. The SELECT expressions are no longer evaluated at the time the data
is pulled out of the table (during the first TableOperation step). All
columns are extracted and a separate new EXPR step is executed at the
end. This means that we have all fields available and don't have to do
any trickery to include virtual fields as part of the plan (such as
"$WHERE") or limit GROUP BY to fields that must also be present in the
SELECT expressions.
3. The GROUP BY pretty much had to be rewritten. In a nutshell, GROUP BY
will use the expression itself (such as "COUNT(*)") as it's internal
column name allowing for more flexibility.
