MariaDB stored procedures and why they should be improved

MariaDB stored procedures
and why (I think that)
they should be improved

● Why stored procedures are important
● Examples of libraries
● Improvements that we need
Agenda

A user perspective:
● Stored procedures form an API that can be maintained by
most DBAs / DB engineers, whereas developers can keep
using ORMs
● Avoid network I/O overhead, resource consumption
● Shorter locks
● Write it once, call it from everywhere
Why Stored Procedures are useful

A community and vendor perspective:
● Easy way to add callable code to MariaDB
● Easy to distribute and "install"
● Some MariaDB features could have been implemented as
stored procedures in an acceptable way
(by someone who's not a C developer)
KILL QUERY, IF [NOT] EXISTS, SET STATEMENT…
Why Stored Procedures are useful

Currently MariaDB stored procedures:
● Are too slow
● Miss many features that make
development easier or
help generalise the code
● Don't have a native debugger
When why doesn't it happen?

Though MariaDB stored procedures have great improvements
compared to MySQL.
The native language has improvements, such as
EXECUTE IMMEDIATE or BEGIN NOT ATOMIC.
It also has a PL/SQL parser.
But some work is still needed.
But it happened (a bit)

It's half the time used by MySQL…
But come on, it should be instantaneous.

But we had good examples, including:
● common_schema
● MySQL General Purpose
Stored Routines Library
● SecuRich
● Flexviews
● MyTap, utMySQL, STK/Unit
● sql_games

● SQL is great for queries because it describes what you want
in English
● And then procedural constructs were added
● But they resemble prehistoric languages like COBOL
Missing features: External languages

● PostgreSQL supports natively SQL and C
● Support for other languages is implemented by the
community

● The list is here:
https://wiki.postgresql.org/wiki/PL_Matrix
● Both interpreted and compiled
● List includes Python, JavaScript, PHP, Perl, Rust, …

● Python is a sort of lingua franca for both
systems people and data people
● So I recommend to implement it
● But it would probably be impossible to implement venv's
● So I recommend that it's not the only option

Missing features:
Input / Output

To write code that's reusable by many people in many contexts,
parameters need be more flexible. We miss:
● Optional arguments
● Variadic arguments
● Overloading
● RETURNS ON NULL INPUT
Missing features: Input / Output

Output should also be more flexible:
● Table functions
Missing features: Input / Output

MDEV-10862
CREATE FUNCTION get_hash(
string TEXT,
algorithm VARCHAR(20) DEFAULT 'sha512'
)
BEGIN
…
END
Optional arguments

MDEV-524
CREATE FUNCTION csv_list(VARCHAR(50), …)
Add 2 array variables or functions:
● argc()
● argv(offset)
Variadic arguments

(MDEV-23290)
PostgreSQL has this. Procedures can have the same name but
different parameter types.
CREATE FUNCTION get_month_days(month INT, DEFAULT year YEAR)
CREATE FUNCTION get_month_days(month VARCHAR(10), DEFAULT year YEAR)
SELECT get_month_days(12);
SELECT get_month_days('February', 2020);
Overloading

Since version 10.6 we have JSON_TABLE()
which accepts a JSON document and returns a table.
Stored Functions would be much more flexible if they
could return tables.
We also need functions to navigate the returned table
columns and rows.
It would be even better if TABLE becomes a first class type.
Table functions

PostgreSQL has this clause:
● RETURNS ON NULL INPUT / STRICT
Is not executed and returns NULL if one of the arguments is
NULL. It could save a lot of lines of code and it's faster.
● CALLED ON NULL INPUT
Executed normally even if there are NULL arguments.
Table functions

Missing features:
Optimisations

We need some optimisations:
● Inline functions
● DETERMINISTIC / STABLE / IMMUTABLE
● Use DETERMINISTIC functions in generated columns
● COMMUTATOR, NEGATOR, RESTRICTION
Missing Features: Optimisations

Sometimes a function can be inlined.
Inlining a function sometimes allows to use indexes.
CREATE FUNCTION pos_less_than(num INT, maxnum INT)
BEGIN
RETURN num < 0 AND num < maxnum;
END;
SELECT * FROM orders
WHERE pos_less_then(cost, 1000)
=> WHERE cost > 0 AND cost < 1000
Inline Functions

● MariaDB has DETERMINISTIC but specifying it has no
effect. Deterministic routines arguments and results should
be cached.
● STABLE is used in PostgreSQL. It means that a function is
deterministic for the current query only.
● Exception: a routine shouldn't be cached if it
MODIFIES SQL DATA

● PostgreSQL supports CREATE OPERATOR
● An operator is:
○ A function
○ + some hints for the optimiser

● Allow function authors to specify hints, such as:
○ Hints on function execution cost
○ A commutator function (eg: > and <)
○ A negator function (eg: > and =<)
○ Restriction (eqsel, neqsel, …, UDF)

● Arrays
● Polymorphic types

MDEV-6121
● At least for stored routines and variables
● If external languages are supported, they'll have good array
support
● But MariaDB should be able, at least, to pass arrays as
arguments and return them from functions
Arrays

MDEV-18951
Any type can be converted to a string, but sometimes doing so
would bring too many problems (different order, inaccurate
conversions).
An ANY type would make things easy.
CREATE FUNCTION is_ordered(v1, v2)
BEGIN
RETURN v1 < v2;
END
Polymorphic types

MariaDB stored procedures and why they should be improved

MariaDB stored procedures and why they should be improved

More Related Content

Similar to MariaDB stored procedures and why they should be improved (20)

More from Federico Razzoli (20)

Recently uploaded (20)

MariaDB stored procedures and why they should be improved