From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-f195.google.com (mail-lj1-f195.google.com [209.85.208.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 4B6A843D67A for ; Thu, 17 Oct 2019 22:20:12 +0300 (MSK) Received: by mail-lj1-f195.google.com with SMTP id m7so3761822lji.2 for ; Thu, 17 Oct 2019 12:20:12 -0700 (PDT) Date: Thu, 17 Oct 2019 22:20:09 +0300 From: Konstantin Osipov Message-ID: <20191017192009.GA19182@atlas> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Tarantool-patches] [tarantool-patches] [PATCH v1 1/1] sql: fix fk violation for autoincremented field List-Id: Tarantool development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: tarantool-patches@freelists.org Cc: tarantool-patches@dev.tarantool.org * Kirill Shcherbatov [19/10/17 17:36]: > Fk constraints used to ignore incremented fields that are > represented with NULL placeholders in a tuple during FK tests in > the SQL frontend. A factual value is inserted in a tuple a bit > later, during DML 'insert' operation on the server side. > > To work around this issue a new OP_NextSequenceValue opcode is > introduced. This new operation retrieves a next sequence value > (that will be factually inserted in a tuple later) to test it > for fk constraint compatibility. If you added a method to query the next sequence value, why don't you set it in SQL? This way you don't have to query it, you increment and use it in SQL right away. -- Konstantin Osipov, Moscow, Russia