[tarantool-patches] Re: [PATCH v3 1/3] schema: add new system space for CHECK constraints

[Kirill Shcherbatov <kshcherbatov@tarantool.org>]

>>> tarantool> create table t2(id int primary key, constraint fk1 foreign key(id) references t2, constraint fk1 foreign key(id) references t2)
>>> ---
>>> - error: Constraint FK1 already exists
>>> ...
>>>
>>
>> And this is a bug in FK
>> https://github.com/tarantool/tarantool/issues/4183
> 
> Still, we have an option to fix it: display proper error message and
> process clean-up. Please, add a mention that in scope of issue we
> should also use vdbe_emit_halt_with_presence_test for CK constraints
Can't understand what do you mean. This is a problem with incorrect usage of
vdbe_emit_halt_with_presence_test #4183. We may introduce another one
bug beautifying this error, but should we?
Although this is unrelated problem and I don't care with error would
be raised here.

>> At first, there is no way to control this state as you propose.
> 
> Ok, then we should come up with machinery which will allow us
> to disable CK constraints, but not other NoSQL triggers.> 
>> Next, disabling/enabling triggers is required for upgrade() functionality
>> and is not a part of public API.
> 
> From user’s point of view checks are constraints. AFAIR Konstantin
> asked for a handle to disable check and foreign key constraints.
Again, what does turning checks on and off have to do with their
server integration?

>> So, I've reject xfer optimization when source or destination space has
>> ck constraints.
> 
> This optimisation doesn’t seem to be vital. On the other hand, if we can
> use it, why not to do so?
Because in the next patch supporting this change becomes quite expensive
and pointless, we discussed it in telegram and you agreed.