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

* n.pettik <korablev@tarantool.org> [19/05/14 21:26]:

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(...)
}

I believe I understand how it works now. 

What is the problem in fixing it? In scope of this patch set or a
different one is another issue.


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