[Tarantool-discussions] SQL built-in functions position

Vladislav Shpilevoy v.shpilevoy at tarantool.org
Mon Sep 28 23:07:49 MSK 2020


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?".

More information about the Tarantool-discussions mailing list