This document discusses improvements that could be made to MariaDB stored procedures. It begins by explaining why stored procedures are useful from a user and community perspective. It then outlines currently limitations with MariaDB stored procedures, such as them being too slow and missing features that make development easier. The document proposes several specific improvements, such as supporting external programming languages like Python, adding more flexible input/output features, and implementing optimizations like inline functions and deterministic function caching. It concludes by suggesting adding support for array types and polymorphic types to MariaDB stored procedures.

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

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

3. 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

4. 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

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

6. 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)

7. It's half the time used by MySQL…
But come on, it should be instantaneous.
But it happened (a bit)

8. But we had good examples, including:
● common_schema
● MySQL General Purpose
Stored Routines Library
● SecuRich
● Flexviews
● MyTap, utMySQL, STK/Unit
● sql_games
But it happened (a bit)

9. External languages

10. ● 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

11. ● PostgreSQL supports natively SQL and C
● Support for other languages is implemented by the
community
Missing features: External languages

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

13. ● 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: External languages

14. Missing features:
Input / Output

15. 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

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

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

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

19. (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

20. 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

21. 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

22. Missing features:
Optimisations

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

24. 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

25. ● 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
Missing Features: Optimisations

26. ● PostgreSQL supports CREATE OPERATOR
● An operator is:
○ A function
○ + some hints for the optimiser
Missing Features: Optimisations

27. ● 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)
Missing Features: Optimisations

28. Missing features:
Types

29. ● Arrays
● Polymorphic types
Missing Features: Optimisations

30. 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

31. 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