From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <v.shpilevoy@tarantool.org>
Received: from smtpng3.m.smailru.net (smtpng3.m.smailru.net [94.100.177.149])
 (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 31ACE44643A
 for <tarantool-discussions@dev.tarantool.org>;
 Mon, 28 Sep 2020 23:07:53 +0300 (MSK)
References: <66362762-8791-bea3-745f-afc1e3eaa199@tarantool.org>
 <9a788a90-f558-fc6c-1d28-2813e8b721f8@ocelot.ca>
From: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Message-ID: <57513bb5-3a4d-0c3c-720e-7e78634ecfe1@tarantool.org>
Date: Mon, 28 Sep 2020 22:07:49 +0200
MIME-Version: 1.0
In-Reply-To: <9a788a90-f558-fc6c-1d28-2813e8b721f8@ocelot.ca>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Subject: Re: [Tarantool-discussions] SQL built-in functions position
List-Id: Tarantool development process
 <tarantool-discussions.dev.tarantool.org>
List-Unsubscribe: <https://lists.tarantool.org/mailman/options/tarantool-discussions>, 
 <mailto:tarantool-discussions-request@dev.tarantool.org?subject=unsubscribe>
List-Archive: <https://lists.tarantool.org/pipermail/tarantool-discussions/>
List-Post: <mailto:tarantool-discussions@dev.tarantool.org>
List-Help: <mailto:tarantool-discussions-request@dev.tarantool.org?subject=help>
List-Subscribe: <https://lists.tarantool.org/mailman/listinfo/tarantool-discussions>, 
 <mailto:tarantool-discussions-request@dev.tarantool.org?subject=subscribe>
To: Peter Gulutzan <pgulutzan@ocelot.ca>, Mergen Imeev <imeevma@tarantool.org>, Nikita Pettik <korablev@tarantool.org>, kyukhin@tarantool.org, tsafin@tarantool.org, sergos@tarantool.org
Cc: tarantool-discussions@dev.tarantool.org

Hi!

See my response in another email with 4 big reasons why
storage of SQL-specific functions in _func is a bad idea.

Also see responses on your comments in separate sections.
I leave references below.

> The current built-in functions are harmless, except perhaps for RANDOMBLOB with a huge value.
> However, in future maybe there will be built-in functions that should require privileges.
> In that case, I believe, they will have to be in _func (and someday in _vfunc)
> so that grant() will work for them.

See "## Built-in functions require privileges?".

> I have tried to redirect the UPPER() function in order to violate security, thus:
> "
> tarantool> function UPPER(x) return x end
> ---
> ...
> tarantool> box.schema.func.create('UPPER')
> ---
> - error: Function 'UPPER' already exists
> ...
> tarantool> box.schema.func.drop('UPPER')
> ---
> - error: 'Can''t drop function 1: function is SQL built-in'
> ...
> "
> This is good behaviour and I think it works because UPPER() is in _func.

See "## Built-in functions prevent duplicates in _func?".

> I did not document in the manual's SQL section that built-in functions will
> be in _func, so removing them is not a regression from documented behaviour.

See "## Storage in _func does not change _func schema and documentation?".

> But I think users benefit from being able to see them.

See "## Users benefit from seeing SQL-specific functions in _func?".