[tarantool-patches] Re: [PATCH] sql: xfer optimization issue
Alexander Turenko
alexander.turenko at tarantool.org
Thu Jun 28 13:18:39 MSK 2018
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.
More information about the Tarantool-patches
mailing list