[tarantool-patches] Re: [PATCH] sql: xfer optimization issue

[Alexander Turenko <alexander.turenko@tarantool.org>]

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.