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

["n.pettik" <korablev@tarantool.org>]

> On 12 May 2019, at 18:52, Kirill Shcherbatov <kshcherbatov@tarantool.org> wrote:
> 
>>>> 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?

I don’t ask you to add another one bug, but ask you to file this
problem to not forget to fix it when smb will implement #4183.

> 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?

You broke optimisation, I suggest way (turning CK constraints on/off) to fix that.
It is not about current patch, but rather about the next one.

>>> 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.

Agh, AFAIR we decided to turn it on when strings of expressions are equal.
If you don’t really want to introduce handle disabling check constraints now,
then add FIXME comment and open an issue (sql: add handle to disable
constraints). That’s it.