The map requires plan is uniqueness among the syntax nodes, but
CTE violates this restrictions. So, migrate to the stack traversal.

Previously sbroad used ordinary Rust's `RefCell` for smart pointer behaviour.
It's pretty dangerous in tarantool environment, as it will be human responsibility to
check that no yield happens before `RefCell` is unlocked.

It causes problems with, for instance, cartridge's `apply_config` during live load - 
it needs to exclusively borrow the metadata, but it's already borrowed by ordinary insert requests.

- to_char(datetime, format), format is specified
as in `strftime` function:
https://man.freebsd.org/cgi/man.cgi?query=strftime&sektion=3

Previous implementation treated TRIM as an SQL built-in function,
but in reality it is a special expression in SQL. The main difference
is that "TRIM" is not a name but a reserved keyword, so it can't
be wrapped into double quotes. Moreover, if we treat it as a function,
we need some special hacks to handle a complicated logic in its
arguments. Now TRIM is a separated expression with a custom parsing
logic.

At the moment we use String type for strings in Plan
structure. Since we frequently serialize, deserialize
and clone Plan, we want to reduce the time spent in
these functions. This commit substitutes String type
with SmolStr type, which has O(1) clone and, therefore,
speeds up cloning.

Previously we had problems parsing arithmetic operations like `b*b`.
Because of incorrect handling of the forbidden symbols in the names
we recognized `b*b` as a column name rather then a multiplication.

Arseniy Volynets authored 1 year ago and Denis Smirnov committed 1 year ago

- Detect when except, groupby, join or eqality
with subqueries is done on bucket_id column
to avoid adding extra motions

- For queries that want to join on
bucket_id column, we had wrong logic
of removing that column from child scan,
now if we have bucket_id column in
join we won't delete bucket_id from scan
node.
- Fix conflict resolution for join on
bucket_id: if we see that join is done
on bucket_id, we don't need any motions.

Note: there is still a problem when we don't
use "bucket_id" in join condition:

select t1."bucket_id", t2."bucket_id" from t1
join t2 on ...

This query will fail with error that it can't
find "bucket_id" column.