[tarantool-patches] Re: [PATCH v3 0/3] box: run checks on insertions in LUA spaces

[Konstantin Osipov <kostja@tarantool.org>]

* 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