From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <tarantool-patches-bounce@freelists.org>
Received: from localhost (localhost [127.0.0.1])
	by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 9CCAE22147
	for <tarantool-patches@freelists.org>; Sat, 29 Dec 2018 08:26:20 -0500 (EST)
Received: from turing.freelists.org ([127.0.0.1])
	by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 3gMdIxvgwyxG for <tarantool-patches@freelists.org>;
	Sat, 29 Dec 2018 08:26:20 -0500 (EST)
Received: from smtp57.i.mail.ru (smtp57.i.mail.ru [217.69.128.37])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id 5A363201C7
	for <tarantool-patches@freelists.org>; Sat, 29 Dec 2018 08:26:20 -0500 (EST)
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
Subject: [tarantool-patches] Re: [PATCH v2 3/5] sql: fix fkey exception for self-referenced table
From: "n.pettik" <korablev@tarantool.org>
In-Reply-To: <e9484074ecd92eed341a3327504b2b7ccfc21b77.1546079994.git.kshcherbatov@tarantool.org>
Date: Sat, 29 Dec 2018 15:26:17 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <B149ECA7-7C17-4AC8-AFE4-3A31EDE35879@tarantool.org>
References: <cover.1546079994.git.kshcherbatov@tarantool.org>
 <e9484074ecd92eed341a3327504b2b7ccfc21b77.1546079994.git.kshcherbatov@tarantool.org>
Sender: tarantool-patches-bounce@freelists.org
Errors-to: tarantool-patches-bounce@freelists.org
Reply-To: tarantool-patches@freelists.org
List-help: <mailto:ecartis@freelists.org?Subject=help>
List-unsubscribe: <tarantool-patches-request@freelists.org?Subject=unsubscribe>
List-software: Ecartis version 1.0.0
List-Id: tarantool-patches <tarantool-patches.freelists.org>
List-subscribe: <tarantool-patches-request@freelists.org?Subject=subscribe>
List-owner: <mailto:>
List-post: <mailto:tarantool-patches@freelists.org>
List-archive: <http://www.freelists.org/archives/tarantool-patches>
To: tarantool-patches@freelists.org
Cc: Kirill Shcherbatov <kshcherbatov@tarantool.org>


> UPDATE operation doesn't fail when fkey self-reference condition
> unsatisfied, when table has other records.

Nit: ... and table has other records.

> To do not raise error where it is not necessary Vdbe makes

It is russian-like collocation, we can=E2=80=99t =E2=80=98make=E2=80=99 =
lookup.

"=E2=80=A6 Vdbe inspects parent table emitting OP_Found" (or smth like =
this)=20

> lookup in parent table with OP_Found. This branch is not valid
> for self-referenced table since its looking for a tuple affected
> by UPDATE operation and since the foreign key has already
> detected a conflict it mast be raised.

Nit: must.

Sorry for being so picky.

>=20
> Example:
> CREATE TABLE t6(a INTEGER PRIMARY KEY, b TEXT, c INT, d TEXT, =
UNIQUE(a, b),
>                FOREIGN KEY(c, d) REFERENCES t6(a, b));
> INSERT INTO t6 VALUES(1, 'a', 1, 'a');
> INSERT INTO t6 VALUES(100, 'one', 100, 'one');
> UPDATE t6 SET c =3D 1, d =3D 'a' WHERE a =3D 100;
> -- fk conflict must be raised here
>=20
> Needed for #3850
> Closes #3918
> =E2=80=94

Patch itself is OK.
Anyway, I am still interested why SQLite demonstrates
this behaviour. I believe they know about it and don't
fix it so far.