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 A86A62001A
	for <tarantool-patches@freelists.org>; Thu, 28 Jun 2018 06:18:41 -0400 (EDT)
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 PsmBVGuoFRnm for <tarantool-patches@freelists.org>;
	Thu, 28 Jun 2018 06:18:41 -0400 (EDT)
Received: from smtp50.i.mail.ru (smtp50.i.mail.ru [94.100.177.110])
	(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 0922824EEB
	for <tarantool-patches@freelists.org>; Thu, 28 Jun 2018 06:18:40 -0400 (EDT)
Date: Thu, 28 Jun 2018 13:18:39 +0300
From: Alexander Turenko <alexander.turenko@tarantool.org>
Subject: [tarantool-patches] Re: [PATCH] sql: xfer optimization issue
Message-ID: <20180628101839.fhnijezdpwviohop@tkn_work_nb>
References: <08FAE06B-F6D3-49BD-9011-B5770629AA21@tarantool.org>
 <CAEi+_aoTp-jnAtSZXMqo4EACEDS20Rwkvw+yCsH9pKz8X05Y7w@mail.gmail.com>
 <5BB99B27-5F86-4664-AAD5-57A22ECED854@tarantool.org>
 <CAEi+_aoOeCAsdf8QdP2tPqZYRJmzfW=vOBgAtAx2+ZnROMJJZA@mail.gmail.com>
 <A120DC35-6ACA-48DF-8A68-531A31B39B8D@tarantool.org>
 <CAEi+_aos_j278_E-j9UsDcoqPm3Bd=E2oTQo_qBrFOOwx8sZUw@mail.gmail.com>
 <93E4DAEA-EF90-479D-9F62-3D1CEB3CBE3F@tarantool.org>
 <CAEi+_aqxW-RPhC5tFBPQSmPewR48SSnDMiB2_iw6Etzpqrni4Q@mail.gmail.com>
 <F68261EE-EDE3-48FA-9864-7BA2653798B0@tarantool.org>
 <CAEi+_arx_rHJGAqafDYT83fRFSUhqQZ58-C3rvYg38jxdf_Fig@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAEi+_arx_rHJGAqafDYT83fRFSUhqQZ58-C3rvYg38jxdf_Fig@mail.gmail.com>
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: Kirill Yukhin <kyukhin@tarantool.org>, Nikita Pettik <korablev@tarantool.org>
Cc: tarantool-patches@freelists.org, Hollow111 <hollow653@gmail.com>

On Fri, May 04, 2018 at 12:54:30PM +0000, Hollow111 wrote:
>    > @@ -1737,8 +1744,10 @@ xferOptimization(Parse * pParse,       /*
>    Parser context */
>    >       if (onError == ON_CONFLICT_ACTION_DEFAULT) {
>    >               if (pDest->iPKey >= 0)
>    >                       onError = pDest->keyConf;
>    > -             if (onError == ON_CONFLICT_ACTION_DEFAULT)
>    > +             if (onError == ON_CONFLICT_ACTION_DEFAULT) {
>    >                       onError = ON_CONFLICT_ACTION_ABORT;
>    > +                     confl_action_default = 1;
>    Why do you need this variable at all? I mean, DEFAULT always
>    is an alias to ABORT, isn’t it?
>    Yes, it is, but there's a little difference between directly specified
>    ABORT for an
>    insert stmt (INSERT OR ABORT) and just INSERT without any specified
>    error action
>    (ABORT specified by the internals). When you directly specify it ABORT
>    is a higher priority
>    action than in case there's a column with REPLACE error action. Thus we
>    can even insert
>    not in the empty destination table.

If an user asks for ABORT explicitly we should make abort, I think.

As I understood the extra variable appears due to the fact than we can
have per-column conflict clauses in CREATE TABLE and per-table clause
with INSERT OR ABORT. The latter should have precedence, I think.

I don't sure whether something (behaviour? code?) should be different
from SQLite here in light of #2963 changes. Kirill, Nikita, can you
comment, please?

WBR, Alexander Turenko.