Uploading a patch for this functionality (only for comments at this
point). It does not yet contain a new JUnit test for the feature,
I'll add that in the next spin.
I have tested the patch ad hoc, and it seems for work for what I have
thrown at it so far.
Since this feature cuts across a lot of underlying result sets and
modes (read-only, scrollable, updatable, subqueries etc), it is hard
to write an exhaustive test. To test whether the presence of an
additional result set on top of other result sets breaks anything, I
have done the following experiment: I modified the parser so as to
always stick in an OFFSET 0 ROWS clause for a top level SELECT. This
should have no impact on the result set returned. With that
modification, I ran the regressions. I uncovered some small issues
with updatable result sets in this way. Presently, the only tests
which fail are canon based tests which compare the execution plan with
a canon (a diff is to be expected here). For a couple of those I
compared the plans manually to verify that the only difference was the
presence of a wrapper result set.
Add the new syntax and stick offset/fetch first values into CursorNode.
Accommodate the new node type RowCountNode.
This node is inserted at optimize time, see CursorNode,
DMLStatementNode changes. At generation time it will insert a
RowCountResultSet over the top SELECTs result set, but underneath any
Adds copying of table name and schema name to the cloneMe method. his
was needed to handle updatable result sets which expect to see the
table name in the top result columns. Is this change safe?
Bind offset/fetch first values (type check, range check) and add a
RowCountNode to the abstract syntax tree at optimize time. I found
that inserting this node prior to optimizing the underlying query did
not work, notably GROUP BY failed.
Added a method to check if a value is an integer or a bigint, needed
at bind time of the row counts.
This new result set implements the filtering required by this
functionality. It mostly forwards to it child result set otherwise.
Adds run time statistics handling for the new result set.
Relaxed a "final" to be able to override clearCurrentRow in
RowCountResultSet. RowCountResultSet#clearCurrentRow actually calls
clearCurrentRow of its source result set, since
RowCountResultSet#getCurrentRow also asks its source result set for
the current row. Forwarding these to the child, may not be entirely
kosher, but I had to do it this way to make it work with the updatable
cursors. Suggestions of better ways to handle this are welcome.
updateRow will look at the result set for a top ProjectRestrictNode
and use it for projection. I added code here to get at the
ProjectRestrictNode from underneath a RowCountResultSet.
Accommodate the new result set type.
Made BIGINT_ID public, needed by the new method in ValueNode (checkIsInteger).
New error messages/execution plan i18n strings and English text for