From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <korablev@tarantool.org>
Received: from smtp40.i.mail.ru (smtp40.i.mail.ru [94.100.177.100])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by dev.tarantool.org (Postfix) with ESMTPS id 0ADC44696C3
 for <tarantool-patches@dev.tarantool.org>;
 Mon,  6 Apr 2020 15:15:51 +0300 (MSK)
Date: Mon, 6 Apr 2020 12:15:51 +0000
From: Nikita Pettik <korablev@tarantool.org>
Message-ID: <20200406121551.GD20849@tarantool.org>
References: <a950d9b0064a61901c71355afa4bf69a8d639545.1585936372.git.korablev@tarantool.org>
 <CADqioP3VAyY6Y4w2nP6u=u+DOF7Usbn+i4D_QxMy_RrD2edyfw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CADqioP3VAyY6Y4w2nP6u=u+DOF7Usbn+i4D_QxMy_RrD2edyfw@mail.gmail.com>
Subject: Re: [Tarantool-patches] [PATCH] sql: reset values to be bound after
 execution
List-Id: Tarantool development patches <tarantool-patches.dev.tarantool.org>
List-Unsubscribe: <https://lists.tarantool.org/mailman/options/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=unsubscribe>
List-Archive: <https://lists.tarantool.org/pipermail/tarantool-patches/>
List-Post: <mailto:tarantool-patches@dev.tarantool.org>
List-Help: <mailto:tarantool-patches-request@dev.tarantool.org?subject=help>
List-Subscribe: <https://lists.tarantool.org/mailman/listinfo/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=subscribe>
To: Eugene Leonovich <gen.work@gmail.com>
Cc: tarantool-patches@dev.tarantool.org, v.shpilevoy@tarantool.org

On 03 Apr 23:23, Eugene Leonovich wrote:
> On Fri, Apr 3, 2020 at 8:22 PM Nikita Pettik <korablev@tarantool.org> wrote:
> 
> > +execute(s.stmt_id, {{[':a'] = 1}, {[':b'] = 2}});
> > + | ---
> > + | - metadata:
> > + |   - name: :a
> > + |     type: integer
> > + |   - name: :b
> > + |     type: integer
> > + |   - name: :c
> > + |     type: boolean
> > + |   rows:
> > + |   - [1, 2, null]
> >
> 
> I wonder, shouldn't an error be thrown if there are not enough parameters
> passed?

I guess it works just as it was implemented long ago. Some users may
rely on this 'feature'. So personally I would rather not change it.

> I just checked Postgres and MySQL, optional parameters are forbidden on
> both systems:
> 
> Postgres
> ------------------------------------------------------------------------------------------
> PREPARE foo (int, int, int) AS SELECT $1, $2, $3;
> EXECUTE foo(1, 2, 3);
>  ?column? | ?column? | ?column?
> ----------+----------+----------
>         1 |        2 |        3
> (1 row)
> 
> EXECUTE foo(1, 2);
> ERROR:  wrong number of parameters for prepared statement "foo"
> DETAIL:  Expected 3 parameters but got 2.
> ------------------------------------------------------------------------------------------
> 
> MySQL
> ------------------------------------------------------------------------------------------
> PREPARE foo FROM 'SELECT ?, ?, ?';
> 
> 
> SET @a = 1;
> 
> 
> SET @b = 2;
> 
> 
> SET @c = 3;
> EXECUTE foo USING @a, @b, @c;
> +------+------+------+
> | ?    | ?    | ?    |
> +------+------+------+
> | 0x31 | 0x32 | 0x33 |
> +------+------+------+
> 
> EXECUTE foo USING @a, @b;
> ERROR 1210 (HY000): Incorrect arguments to EXECUTE
> ------------------------------------------------------------------------------------------
> 
> 
> -- 
> Thank you and best regards,
> Eugene Leonovich