Implement recursive processing for compound SELECT statements by
dividing them into two components:
1. left: a vector containing a SELECT core and its associated compound
operator
2. right_most: the rightmost SELECT core in the compound statement
Based on the compound operator, we can determine how to process the
rightmost part and recursively handle the left component.
Following this refactor, we can seamlessly integrate support for
`INTERSECT` and `EXCEPT` operations.
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#1718
Closes#1717
We were incorrectly setting `moved_before` as `false` after checking for
unique constraint violation, but the reality is that after the
uniqueness check, we are already correctly positioned -- if no match was
found, the cursor is positioned at either:
a) no row, or
b) at the first entry that is greater than the key we are inserting.
This means we don't have to move anymore and can just insert.
Reviewed-by: Pere Diaz Bou <pere-altea@homail.com>
Closes#1723
We were incorrectly setting `moved_before` as `false` after checking
for unique constraint violation, but the reality is that after the
uniqueness check, we are already correctly positioned -- if no match
was found, the cursor is positioned at either:
a) no row, or
b) at the first entry that is greater than the key we are inserting.
This means we don't have to move anymore and can just insert.
Adds an `#[instrument]` to many btree related functions. Also, when
debugging #1717 it would be impossible to debug as the 10Mb SeekKey
would be printed to my terminal making the experience miserable. The
debug implementation now truncates the Blobs and Strings when they are
too big to be useful.
Closes#1721
also added a `cursor_loop` helper on `ProgramBuilder` to avoid making
this mistake in the future. this is zero-cost, and will be optimized to
the same thing (hopefully).
