On 14 May 2019, at 20:00, Konstantin Osipov <kostja@tarantool.org> wrote:

* Kirill Shcherbatov <kshcherbatov@tarantool.org> [19/05/14 18:04]:
@v.shpilevoy
Yes, I will. Kirill, please, send it again in a new thread. You can keep
version 3 and omit change list.

@kostya
It's better to fetch the bound field upon first access.
Most paths of the CHECK constraint may not touch most of the
fields.
I have no idea, how, to fit it in our architecture.
OP_Column has no intersections with binding machinery.

Well, I agree something like OP_fetch is necessary.

We can’t we simply do this:

Add to ck_constraint array of used field numbers -
that’s done during ck_constraint_program_compile()
while we have struct Expr by traversing AST. Then,
we emit OP_Variable ck_field_count times, where
ck_field_count is length of array of used field numbers.

Part of code responsible for CK code generation is:

case TK_COLUMN:{
             int iTab = pExpr->iTable;
             int col = pExpr->iColumn;
             if (iTab < 0) {
                    if (pParse->ckBase > 0) {
                           /* Generating CHECK constraints. */
                           return col + pParse->ckBase;
                    }

So we have to pass that array to parsing context.
Using that array code will look like this:

…
for (int i = 0; i < ck_field_count; ++i) {
if (ck_fields[i] == col)
return ck_fields[i];
}
assert(0);

When it’s time to run program, we go through array
and assign only fields present there:

…
for (int i = 0; i < ck_field_count; ++i) {
sql_bind_decode(&bind, ck_fields[i])
sql_bind_column(...)
}

Fire CK constraints for LUA spaces.
To achieve this goal, we reworked data dictionary, to store ck
constraints in separate space _ck_constraints and updated data
migration script to migrate existent data there. This also would
be useful in future to implement ALTER SPACE ADD CONSTRAINT
operation. Now we do not support CK constraint creation on
non-empty space.

Is there a ticket for adding CHECK constraint on a non-empty
space?

We need to add a general do-any-alter-by-rebuild algorithm so that
all such features work by rebuilding a table. We could optimize
these later.

*No* SQL feature is usable unless DDL related to this feature
works on a non-empty space, at least somehow.

Each CK has own precompiled VDBE machine that performs this
check with tuple fields mapped to it's memory with sql_bind() api.

Good.

--
Konstantin Osipov, Moscow, Russia, +7 903 626 22 32