Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Extending MariaDB the Easy Way: A Tour d’Horizo...

Sponsored · SiteGround - Reliable hosting with speed, security, and support you can count on.
Avatar for lefred lefred
September 09, 2026

Extending MariaDB the Easy Way: A Tour d’Horizon of Server Plugins

MariaDB is not only a database server you configure and operate; it is also a platform you can extend. With server plugins, you can add new SQL functions, expose operational capabilities, experiment with new data types, or adapt server behavior to your own needs without maintaining a long-lived fork.

In this session, I will show how approachable MariaDB Server plugin development can be. After a short introduction to the MariaDB plugin architecture, build process, installation, and testing workflow, we will take a practical tour d’horizon of several real plugins I created.

The examples will cover different plugin use cases: GTID inspection and flashback helpers, disabling selected built-in SQL functions, adding small utility functions, IP address classification and CIDR matching, richer UUID manipulation, timestamp extraction from UUIDv1 and UUIDv7 values, SQL-driven tcmalloc/gperftools profiling, and even extending MariaDB with a custom MONEY type using the Type Handler framework.

The goal is not only to present the plugins themselves, but to demystify the process. Attendees should leave with a clear mental model of what can be extended, how a plugin is structured, how to build and test one, and where MariaDB plugins can be useful in real-world production, troubleshooting, observability, and developer experience scenarios.

Avatar for lefred

lefred

September 09, 2026

More Decks by lefred

Other Decks in Technology

Transcript

  1. Extending MariaDB the Easy Way A Tour d'Horizon of Server

    Plugins plugins forMariaDB Frédéric Descamps Community Advocate MariaDB Foundation Percona Live Europe / Amsterdam - September 2026
  2. Frédéric Descamps • @lefred • @lefredbe.bsky.social • @[email protected] • MariaDB

    Community Advocate since 2026 • using MySQL since version 3.20 • devops believer • living in • https://lefred.be 3 Copyright @ 2026 MariaDB Foundation.
  3. MariaDB Foundation — the 30-second version Our mission: keep MariaDB

    Server thriving, evolving, open and sustainable for the long term. 5 Copyright @ 2026 MariaDB Foundation.
  4. MariaDB Foundation — the 30-second version Our mission: keep MariaDB

    Server thriving, evolving, open and sustainable for the long term. Three cornerstones What we actually do Adoption Grow usage, communities and ecosystem choice. • community, meetups and developer outreach Openness Transparent development, open-source governance and contributions. • enable and guide community contributions Continuity Long-term maintenance, stewardship and technical sustainability. • documentation and migration support 5 Copyright @ 2026 MariaDB Foundation. • build, test and benchmark infrastructure • develop the Community Server • grow ecosystem visibility — including Ecohub
  5. MariaDB Foundation — the 30-second version Our mission: keep MariaDB

    Server thriving, evolving, open and sustainable for the long term. Three cornerstones What we actually do Adoption • community, meetups and developer outreach GrowMariaDB usage, communities ecosystem Foundation and ≠ MariaDB plcchoice. — the Foundation focuses on open-source governance, community development • build, test and services benchmark and ecosystem growth; MariaDB plc focuses on commercial products, enterprise andinfrastructure its product roadmap. Openness • enable and guide community contributions Transparent development, open-source governance and contributions. • develop the Community Server Continuity Long-term maintenance, stewardship and technical sustainability. 5 Copyright @ 2026 MariaDB Foundation. • documentation and migration support • grow ecosystem visibility — including Ecohub
  6. The idea behind this talk “I need one small thing

    in the server...” The traditional options: • wait for the feature • change the application • maintain a server patch • maintain a fork ...or use a plugin. 8 Copyright @ 2026 MariaDB Foundation.
  7. What can you plug into MariaDB? Change what SQL can

    do The Change what the server can do Function plugins Add native-like SQL functions. Storage engines Own the table storage/access path. Data type plugins Add types with parsing, validation, formatting and storage semantics. Daemon plugins Run background/server-side behavior. INFORMATION_SCHEMA plugins Expose new virtual metadata tables. 9 Copyright @ 2026 MariaDB Foundation. Authentication / Audit / Replication / ... Hook into specialized server subsystems. server already speaks “plugin”.
  8. What we will do 1. Build a mental model of

    the MariaDB plugin architecture 2. Build, install and test a small plugin 3. Tour five plugin families 4. Use real examples to see where each family fits 5. Finish with MariaDB's most unique extension point: data types Storage Engine ↓ INFORMATION_SCHEMA ↓ Daemon ↓ Functions ↓ Data Types 10 Copyright @ 2026 MariaDB Foundation.
  9. First mental model A plugin is code that MariaDB discovers,

    registers and calls through a defined interface. 11 Copyright @ 2026 MariaDB Foundation.
  10. Plugin lifecycle source code | v CMake target | v

    shared object (.so) | v plugin_dir | v INSTALL SONAME / plugin_load_add | v MariaDB registers the extension | v SQL / server lifecycle calls your code 12 Copyright @ 2026 MariaDB Foundation.
  11. One .so can expose multiple plugins For example, uuid_more.so registers

    several function plugins: uuid_node() uuid_is_ordered() uuid_variant() uuid_to_base64() base64_to_uuid() uuid_canonical() uuid_info() The module is the delivery unit. The individual registered plugins are the server-visible units. 13 Copyright @ 2026 MariaDB Foundation.
  12. Anatomy of a function plugin The pieces The server gets

    • an Item_func_* implementation • function name • a function builder / factory • implementation • a plugin descriptor • author / version • maria_declare_plugin(...) • license • maturity • initialization hooks 14 Copyright @ 2026 MariaDB Foundation.
  13. A real registration example static Plugin_function plugin_descriptor_function_uuid_info( BUILDER(Item_func_uuid_info)); maria_declare_plugin(uuid_more) {

    MariaDB_FUNCTION_PLUGIN, &plugin_descriptor_function_uuid_info, "uuid_info", "lefred", "Function UUID_INFO()", PLUGIN_LICENSE_GPL, 0, 0, 0x0100, NULL, NULL, "1.0", MariaDB_PLUGIN_MATURITY_BETA } maria_declare_plugin_end; 15 Copyright @ 2026 MariaDB Foundation. This is normal MariaDB server code — just outside the core feature set.
  14. Build it Place or link the plugin below the MariaDB

    source tree: server/ plugin/ extra_misc/ CMakeLists.txt plugin.cc ... 16 Copyright @ 2026 MariaDB Foundation. Then build only your target: cmake -S /path/to/server -B /path/to/build \ -DPLUGIN_EXTRA_MISC=DYNAMIC cmake --build /path/to/build \ --target extra_misc
  15. Install it INSTALL SONAME 'extra_misc'; Verify: SELECT plugin_name, plugin_type, plugin_library,

    plugin_description FROM information_schema.PLUGINS WHERE plugin_library = 'extra_misc.so'; And remove it: UNINSTALL SONAME 'extra_misc'; 17 Copyright @ 2026 MariaDB Foundation.
  16. Test it like server code A plugin can ship an

    MTR suite: mysql-test/ extra_misc/ suite.pm t/ basic.test r/ basic.result 18 Copyright @ 2026 MariaDB Foundation.
  17. Test it like server code A plugin can ship an

    MTR suite: mysql-test/ extra_misc/ suite.pm t/ basic.test r/ basic.result 18 Copyright @ 2026 MariaDB Foundation. Run it: cd build/mysql-test ./mtr extra_misc
  18. Test it like server code A plugin can ship an

    MTR suite: mysql-test/ extra_misc/ suite.pm t/ basic.test r/ basic.result 18 Copyright @ 2026 MariaDB Foundation. Run it: cd build/mysql-test ./mtr extra_misc Plugin code deserves server-grade regression tests.
  19. Tour d'Horizon Five plugin families Five different ways to change

    the same server 19 Copyright @ 2026 MariaDB Foundation.
  20. Chapter 1 Storage Engine Plugins Change how MariaDB stores —

    or reaches — a table. 20 Copyright @ 2026 MariaDB Foundation.
  21. MariaDB's storage-engine ecosystem STORAGE ENGINES General purpose ─────────────── InnoDB Aria

    MyISAM Specialized / modern ──────────────────── ColumnStore MyRocks Mroonga Integration ─────────── Spider CONNECT FederatedX MEMORY DuckDB TideSQL / TidesDB S3 Utility / unusual ───────────────────────────────────────────────────────────────── Sequence BLACKHOLE CSV ARCHIVE MERGE OQGRAPH SphinxSE 21 Copyright @ 2026 MariaDB Foundation.
  22. Different engines can optimize for very different things: • transactions

    and OLTP • embedded analytics / columnar execution — DuckDB • modern LSM-tree transactional workloads — TideSQL / TidesDB • compression / write amplification • distributed or remote data • external files and services • virtual or special-purpose tables ENGINE= is already a plugin selector. 22 Copyright @ 2026 MariaDB Foundation.
  23. Recent engines show why plugins still matter DuckDB TideSQL /

    TidesDB Analytical engine Transactional LSM-tree engine • columnar storage • ACID / MVCC • vectorized execution • optimized for modern hardware • parallel analytical processing • secondary indexes • query pushdown • TTL and compression • cross-engine queries • online capabilities CREATE TABLE analytics (...) ENGINE=DuckDB; CREATE TABLE events (...) ENGINE=TidesDB; 23 Copyright @ 2026 MariaDB Foundation.
  24. Recent engines show why plugins still matter DuckDB TideSQL /

    TidesDB Analytical engine Transactional LSM-tree engine • columnar storage • ACID / MVCC • vectorized execution • optimized for modern hardware • parallel analytical processing Two radically different engines. indexes • secondary Same MariaDB storage-engine interface. • query pushdown • TTL and compression • cross-engine queries • online capabilities CREATE TABLE analytics (...) ENGINE=DuckDB; CREATE TABLE events (...) ENGINE=TidesDB; 23 Copyright @ 2026 MariaDB Foundation.
  25. Discover storage-engine plugins with SQL SHOW ENGINES; Then the application

    chooses one through ordinary SQL: CREATE TABLE orders ( id BIGINT PRIMARY KEY, total DECIMAL(12,2) ) ENGINE=InnoDB; 24 Copyright @ 2026 MariaDB Foundation. SELECT ENGINE, SUPPORT, TRANSACTIONS, COMMENT FROM information_schema.ENGINES; Another table can choose another engine: CREATE TABLE archived_events (...) ENGINE=S3;
  26. Discover storage-engine plugins with SQL SHOW ENGINES; SELECT ENGINE, SUPPORT,

    TRANSACTIONS, COMMENT FROM information_schema.ENGINES; Then the application chooses one through ordinary SQL: CREATE TABLE orders ( id BIGINT PRIMARY KEY, total DECIMAL(12,2) ) ENGINE=InnoDB; Another table can choose another engine: CREATE TABLE archived_events (...) ENGINE=S3; Same SQL server. Different table implementation. 24 Copyright @ 2026 MariaDB Foundation.
  27. Storage engines can extend more than storage A MariaDB storage

    engine can participate in: • table creation and discovery • row reads / writes • indexes • transactions and locking • statistics and optimizer cost information • table, field and index attributes 25 Copyright @ 2026 MariaDB Foundation.
  28. SQL layer | handler interface | +----------+----------+ | | |

    InnoDB Spider your_engine | | | local data remote anything nodes you build This is a deep plugin interface — but it is still a plugin interface. 26 Copyright @ 2026 MariaDB Foundation.
  29. A plugin can create a virtual SQL table The plugin

    defines: • table name • columns • how rows are populated • optional SHOW / FLUSH behavior Then users simply query it: SELECT * FROM information_schema.MY_PLUGIN_INFO; 28 Copyright @ 2026 MariaDB Foundation.
  30. The data does not have to live in an InnoDB

    table. It can come from: MariaDB internals + Linux /proc + filesystem + native libraries ↓ INFORMATION_SCHEMA rows Observability becomes composable SQL. 29 Copyright @ 2026 MariaDB Foundation.
  31. Great fit for operational plugins Examples from my own experiments:

    OS / process visibility • Process Info Server / host visibility • VMSTAT ◦ /proc/self/task ◦ CPU ◦ thread accounting ◦ memory • OOM Info ◦ OOM killer scores ◦ process memory context 30 Copyright @ 2026 MariaDB Foundation. ◦ disk • Disk Size Info ◦ filesystem / storage usage
  32. Instead of: ssh → shell → /proc → awk →

    monitoring script you can expose: SQL → INFORMATION_SCHEMA → monitoring / DBA tooling 31 Copyright @ 2026 MariaDB Foundation.
  33. Disable selected built-in functions Sometimes extension means subtraction. [mariadb] plugin_load_add=disabled_functions

    disabled_functions_list=SLEEP,COLUMN_LIST,LOAD_FILE Then: SELECT SLEEP(0); -- ERROR 1305: FUNCTION test.SLEEP does not exist Use cases: • reduce an exposed SQL surface • enforce local policy • prevent accidental use of selected built-ins 33 Copyright @ 2026 MariaDB Foundation.
  34. What this teaches us A daemon plugin does not need

    to provide SQL syntax. It can participate in server lifecycle and alter server behavior. startup | +--> plugin init | +--> inspect configuration +--> change registry / state +--> expose variables / status 34 Copyright @ 2026 MariaDB Foundation.
  35. Chapter 4 Function Plugins The easiest place to start. 35

    Copyright @ 2026 MariaDB Foundation.
  36. One plugin family — many use cases SQL FUNCTIONS |

    +--------------------+--------------------+ | | | observability domain logic operations | | | GTID_INFO() CIDR matching FLASHBACK UUID metadata slugify() profiler control binlog helpers formatting DBA helpers Function plugins are especially attractive when the feature is: • stateless or request-scoped • naturally expressed as f(arguments) • reusable by many applications • easy to cover with MTR 36 Copyright @ 2026 MariaDB Foundation.
  37. GTID Info + Flashback The question started simple: “Where is

    this GTID in my retained binary logs?” The plugin grew into helpers such as: SELECT GTID_INFO('0-1-123'); SELECT GTID_AT('2026-07-02 21:03:00'); SELECT BINLOG_GTID_LIST('mysql-bin.000001'); SELECT GTID_LIST_BINLOGS('0-1-123,1-1-45'); Use case: replication troubleshooting and binlog archaeology. 37 Copyright @ 2026 MariaDB Foundation.
  38. GTID inspection becomes operational tooling GTID_INFO() can expose information such

    as: • binlog containing the transaction • event types • start / end position • GTID flags • timestamps • row-image completeness hints SELECT JSON_PRETTY(GTID_INFO('0-1-3'))\G SQL becomes an observability interface to server internals. 38 Copyright @ 2026 MariaDB Foundation.
  39. Flashback: plugins can also act SELECT GTID_FLASHBACK('0-1-123'); SELECT GTID_FLASHBACK_TO('0-1-123'); The

    plugin can generate reverse row-DML from retained binlogs. But it deliberately refuses unsafe cases like missing row DML, incomplete row images, missing GTID anchor, incompatible live table definition The interesting part of an operational plugin is often not what it can do — but what it refuses to do. 39 Copyright @ 2026 MariaDB Foundation.
  40. Small utility functions extra_misc is intentionally boring — and useful.

    SELECT unaccent('Crème brûlée déjà vu'); -- Creme brulee deja vu SELECT slugify('Crème brûlée déjà vu!'); -- creme-brulee-deja-vu SELECT human_number(1234567); -- 1.23M SELECT parse_duration('1h 30m 10.5s'); -- 5410.500 40 Copyright @ 2026 MariaDB Foundation.
  41. The “small function” sweet spot A server function plugin can

    be better than application-side code when: • many applications need the same behavior • the logic belongs close to the data • you want it in SQL, CHECK constraints or generated expressions • you want one implementation instead of five language-specific ones Small, deterministic, well-tested helpers are a great entry point. 41 Copyright @ 2026 MariaDB Foundation.
  42. IP classification + CIDR matching MariaDB already has native INET4

    and INET6 types. A plugin can teach them extra tricks: SELECT ip_class('10.1.2.3'); -- private SELECT ip_class('fe80::1'); -- link-local SELECT cidr_contains('192.168.0.0/16', '192.168.10.20'); -- 1 SELECT cidr_contains('2001:db8::/32', '2001:db9::1'); -- 0 42 Copyright @ 2026 MariaDB Foundation.
  43. Domain-specific does not mean niche code MariaDB Server | +-------------------+-------------------+

    | | | generic helpers | slugify() domain helpers | CIDR matching local policy | disable SLEEP() age() UUID metadata custom types The plugin boundary lets each deployment decide what belongs in its server. 43 Copyright @ 2026 MariaDB Foundation.
  44. Richer UUID manipulation uuid_more exposes metadata and conversions: SELECT uuid_variant(@u);

    SELECT uuid_is_ordered(@u); SELECT uuid_node(@u); SELECT uuid_canonical(@u); SELECT uuid_to_base64(@u); SELECT uuid_info(@u); 44 Copyright @ 2026 MariaDB Foundation. Example: SELECT uuid_info('018bcfe5-687b-7000-8000-000000000000'); -- {"version":7,"variant":"RFC4122", -- "timestamp":1700000000123,"sortable":true}
  45. Extract time from UUIDs UUIDv1 and UUIDv7 contain time information.

    SELECT uuid_version(uuid_v7()); -- 7 SELECT uuid_to_timestamp(uuid_v7()); -- 2026-02-16 19:44:07.776 SELECT uuid_to_unixtime(uuid()); Now SQL can use that metadata: CREATE TABLE events ( id CHAR(36) PRIMARY KEY CHECK (uuid_version(id) = 7), payload TEXT ); 45 Copyright @ 2026 MariaDB Foundation.
  46. One implementation pattern — many functions shared parser | +---------+---------+

    | | | version() timestamp() node() | | | +---------+---------+ | plugin wrappers | SQL API 46 Copyright @ 2026 MariaDB Foundation. Keep parsing and validation in shared code. Keep each SQL wrapper small.
  47. tcmalloc / gperftools profiler What if the operation is not

    “calculate a value”? Start MariaDB with the profiler allocator: LD_PRELOAD=/usr/lib64/libtcmalloc_and_profiler.so mariadbd Then control profiling from SQL: SELECT TCMALLOC_MEMPROF_START(60); SELECT TCMALLOC_MEMPROF_DUMP(); SELECT TCMALLOC_MEMPROF_REPORT(); SELECT TCMALLOC_CPUPROF_START(30); SELECT TCMALLOC_CPUPROF_REPORT(); 47 Copyright @ 2026 MariaDB Foundation.
  48. SQL as a DBA control plane Before With a plugin

    shell access + environment + PID knowledge + signals + file paths + pprof commands SELECT TCMALLOC_MEMPROF_START(); SELECT TCMALLOC_MEMPROF_REPORT(); • privilege checks • server variables • status variables • predictable workflow 48 Copyright @ 2026 MariaDB Foundation.
  49. Privileges matter Operational functions should not become a shortcut around

    server security. For example, profiler functions can check server-level privileges before acting. if (check_global_access(thd, SUPER_ACL)) return true; Plugin APIs make powerful things easy. That makes authorization part of the feature. 49 Copyright @ 2026 MariaDB Foundation.
  50. Chapter 5 Data Type Plugins Teach MariaDB what a value

    is. 50 Copyright @ 2026 MariaDB Foundation.
  51. Why this chapter is special MySQL and MariaDB share many

    classic plugin families: MariaDB ✓ ✓ ✓ MySQL ✓ ✓ ✓ INFORMATION_SCHEMA Authentication / audit ✓ ✓ ✓ ✓ Custom native data type ✓ ✗ Functions Storage engines Daemon plugins ⇽ Type_handler MariaDB can teach the SQL type system new tricks without maintaining a permanent server fork. 51 Copyright @ 2026 MariaDB Foundation.
  52. And then I got very Belgian... What if MariaDB understood

    Belgian company numbers natively? 52 Copyright @ 2026 MariaDB Foundation.
  53. Why not just use VARCHAR(14)? A Belgian enterprise number has

    actual semantics: • several accepted input forms • a canonical representation • a modulo-97 checksum • a VAT representation 0417497106 0417.497.106 BE0417497106 BE 0417.497.106 | v 0417.497.106 • searchable / indexable values • a corresponding real company in a registry 53 Copyright @ 2026 MariaDB Foundation. A domain value is more than a string.
  54. BCE: type + functions + lookup SQL | +-----------+-----------+ |

    | v v column type SQL functions BCE BCE_NUMBER_* | | v +-----+------+ Type_handler_bce | | | v v v formatting registry Field_bce validation lookup | | v +------+------+ canonical dotted | | notation v v local table CBEAPI 54 Copyright @ 2026 MariaDB Foundation. The same plugin can combine: • type semantics • deterministic local functions • optional external enrichment
  55. Build and use BCE cmake --build /path/to/build --target type_bce INSTALL

    SONAME 'type_bce'; CREATE TABLE companies ( id BIGINT UNSIGNED PRIMARY KEY, enterprise_number BCE NOT NULL UNIQUE ); +----+-------------------+ | id | enterprise_number | +----+-------------------+ | 1 | 0417.497.106 | | 2 | 1000.123.448 | +----+-------------------+ INSERT INTO companies VALUES (1, '0417497106'), (2, 'BE 1000.123.448'); SELECT * FROM companies; Accept friendly input. Store one canonical form. 55 Copyright @ 2026 MariaDB Foundation.
  56. The domain logic becomes SQL SELECT BCE_NUMBER_IS_VALID('0417.497.106'); -- 1 SELECT

    BCE_NUMBER_IS_VALID('0417.497.107'); -- 0 SELECT BCE_NUMBER_FORMAT('0417497106'); -- 0417.497.106 For debugging bad data: SELECT BCE_NUMBER_VALIDATE_DETAIL('0417.497.107'); { "valid":false, "reason":"CHECK_DIGIT_MISMATCH", "base":"04174971", "expected":"06", "received":"07" SELECT BCE_NUMBER_COMPACT('BE 0417.497.106'); -- 0417497106 SELECT BCE_NUMBER_VAT('0417.497.106'); -- BE0417497106 56 Copyright @ 2026 MariaDB Foundation. }
  57. And now cross the database boundary A syntactically valid BCE

    number does not mean the company exists. SELECT BCE_NUMBER_EXISTS('0417.497.106'); SELECT BCE_NUMBER_IS_ACTIVE('0417.497.106'); SELECT BCE_NUMBER_INFO('0417.497.106'); Example result: { "enterprise_number": "0417497106", "name": "Example Company", "status": "ACTIVE" } 57 Copyright @ 2026 MariaDB Foundation.
  58. The lookup provider is configurable: SET GLOBAL bce_lookup_provider = 'local';

    -- or: SET GLOBAL bce_lookup_provider = 'cbeapi'; Validation is local and deterministic. Enrichment is explicit and optional. 58 Copyright @ 2026 MariaDB Foundation.
  59. “Easy” is relative Function plugin BCE plugin • focused API

    • custom Type_handler • fast iteration • assignment-time validation • small blast radius • canonical representation • easy MTR coverage • multiple companion functions One plugin can grow from syntax to domain integration. • system variables • local / HTTP lookup provider • caching + error handling 59 Copyright @ 2026 MariaDB Foundation.
  60. When is a plugin the right answer? Good candidates Maybe

    not • shared SQL helper • application-only business logic • observability endpoint • something already expressible cleanly in SQL • operational control • unstable patch touching many subsystems • local security policy • domain-specific type • feature requiring large grammar / optimizer changes • experiment / prototype • code you cannot test or maintain 60 Copyright @ 2026 MariaDB Foundation.
  61. Plugin, stored function, application or fork? Need SQL-visible behavior? |

    +-- pure SQL is enough? ----------> stored function / view | +-- needs native/server internals? | +-- clean extension point? ---> plugin | +-- no extension point? | +-- broadly useful? -> upstream hook / feature | +-- local only? ------> patch/fork as last resort 61 Copyright @ 2026 MariaDB Foundation.
  62. What I learned building these 1. Start with the smallest

    plugin type that solves the problem. 2. Keep MariaDB-facing wrappers thin. 3. Put parsing / validation in reusable code. 4. Treat errors and NULL behavior as API design. 5. Test with MTR from day one. 6. Add privilege checks before adding power. 7. Expect deeper coupling when touching the type system. 62 Copyright @ 2026 MariaDB Foundation.
  63. Your first plugin tomorrow Pick something with one input and

    one output. Examples: IS_PRIVATE_IP(ip) NORMALIZE_PHONE(value) SEMVER_COMPARE(a,b) JSON_DEPTH(doc) MASK_EMAIL(value) 63 Copyright @ 2026 MariaDB Foundation. Then implement only: 1. argument validation 2. return type 3. one function body 4. plugin declaration 5. one MTR test
  64. Vibe coding a MariaDB plugin? Start by letting AI review.

    Then let it test. Only then let it code. Codex · Claude Code · other coding agents 64 Copyright @ 2026 MariaDB Foundation.
  65. Step 1 — use AI as a reviewer Start with

    code you already understand. Review this MariaDB Server plugin for bugs and coding-standard issues. Context: - This is a MariaDB Server plugin, built inside plugin/ - Do not change behavior unless you find a real bug. - Compare the implementation with similar plugins in the MariaDB source tree. - Check memory ownership, NULL handling, error paths, thread safety and server coding conventions. - Check the CMakeLists.txt and plugin registration too. Do not modify anything yet. Return: 1. bugs, ordered by severity 2. coding-standard problems 3. suspicious assumptions 4. missing tests 5. a proposed minimal patch 65 Copyright @ 2026 MariaDB Foundation.
  66. Step 1 — use AI as a reviewer Start with

    code you already understand. Review this MariaDB Server plugin for bugs and coding-standard issues. Context: - This is a MariaDB Server plugin, built inside plugin/ - Do not change behavior unless you find a real bug. - Compare the implementation with similar plugins in the MariaDB source tree. - Check memory ownership, NULL handling, error paths, thread safety and server coding conventions. - Check the CMakeLists.txt and plugin registration too. First ask the AI to explain the code before changing it. Do not modify anything yet. Return: 1. bugs, ordered by severity 2. coding-standard problems 3. suspicious assumptions 4. missing tests 5. a proposed minimal patch 65 Copyright @ 2026 MariaDB Foundation.
  67. Step 2 — let AI create the MTR tests Once

    the API is clear, make the agent prove its assumptions. Create an MTR test suite for this MariaDB Server plugin. Study existing mysql-test suites for similar plugins first. Cover: - INSTALL / UNINSTALL - normal inputs - NULL - empty and malformed inputs - boundary values - expected SQL errors and warnings - repeated calls - behavior after reload Create: mysql-test/<suite>/suite.pm mysql-test/<suite>/t/basic.test mysql-test/<suite>/r/basic.result Run the suite with mysql-test-run.pl and iterate until it passes. Do not weaken expected results to hide a failure. Explain every uncovered edge case. 66 Copyright @ 2026 MariaDB Foundation.
  68. Step 2 — let AI create the MTR tests Once

    the API is clear, make the agent prove its assumptions. Create an MTR test suite for this MariaDB Server plugin. Study existing mysql-test suites for similar plugins first. Cover: - INSTALL / UNINSTALL - normal inputs - NULL - empty and malformed inputs - boundary values - expected SQL errors and warnings - repeated calls - behavior after reload Generated tests are useful only if the agent actually runs them. Create: mysql-test/<suite>/suite.pm mysql-test/<suite>/t/basic.test mysql-test/<suite>/r/basic.result Run the suite with mysql-test-run.pl and iterate until it passes. Do not weaken expected results to hide a failure. Explain every uncovered edge case. 66 Copyright @ 2026 MariaDB Foundation.
  69. Step 3 — now ask AI to build the plugin

    If you are confident, give it a narrow specification and the server tree. Implement a MariaDB Server plugin named `semver`. Goal: - add SEMVER_IS_VALID(str) - add SEMVER_COMPARE(a,b) - return NULL when an input is NULL - reject malformed versions consistently - no external runtime dependency Before coding: 1. inspect 2-3 existing MariaDB function plugins 2. propose the plugin structure and SQL contract 3. identify the relevant MariaDB APIs Then: 4. implement the plugin and CMake target 5. create complete MTR coverage 6. build only the plugin target 7. run the MTR suite 8. review your own diff for coding-standard and memory issues Do not modify unrelated MariaDB Server code. Do not introduce a server patch unless you can explain why the existing plugin API is insufficient. 67 Copyright @ 2026 MariaDB Foundation.
  70. Step 3 — now ask AI to build the plugin

    If you are confident, give it a narrow specification and the server tree. Implement a MariaDB Server plugin named `semver`. Goal: - add SEMVER_IS_VALID(str) - add SEMVER_COMPARE(a,b) - return NULL when an input is NULL - reject malformed versions consistently - no external runtime dependency Before coding: 1. inspect 2-3 existing MariaDB function plugins 2. propose the plugin structure and SQL contract 3. identify the relevant MariaDB APIs Give the model constraints, examples, tests and a definition of done. Then: 4. implement the plugin and CMake target 5. create complete MTR coverage 6. build only the plugin target 7. run the MTR suite 8. review your own diff for coding-standard and memory issues Do not modify unrelated MariaDB Server code. Do not introduce a server patch unless you can explain why the existing plugin API is insufficient. 67 Copyright @ 2026 MariaDB Foundation.
  71. AI-generated code needs provenance If AI materially changes the repository,

    add: AI_CHANGES.md Example: # AI Changes Changes made by Claude (model: `claude-sonnet-5`) via Claude Code. ## 2026-07-26 Follow-up to a code review of the plugin, requested by the user. Two issues were fixed; a third candidate issue was investigated and left unchanged after comparison with MariaDB's own upstream `type_xmltype` plugin (which this plugin's structure is modeled on). - **Removed dead code**: `Field_email::report_wrong_value()` was declared... 68 Copyright @ 2026 MariaDB Foundation.
  72. AI-generated code needs provenance If AI materially changes the repository,

    add: AI_CHANGES.md Example: Record when, tool + exact model, what it changed, and what a human verified. # AI Changes Changes made by Claude (model: `claude-sonnet-5`) via Claude Code. ## 2026-07-26 Follow-up to a code review of the plugin, requested by the user. Two issues were fixed; a third candidate issue was investigated and left unchanged after comparison with MariaDB's own upstream `type_xmltype` plugin (which this plugin's structure is modeled on). - **Removed dead code**: `Field_email::report_wrong_value()` was declared... 68 Copyright @ 2026 MariaDB Foundation.
  73. AI is not the maintainer Let the agent do You

    still own • source-tree exploration • SQL semantics • boilerplate • ABI/API assumptions • repetitive API comparisons • memory safety • test generation • concurrency • build / MTR iterations • privileges / security • first-pass review • compatibility “The tests pass” is evidence — not authorship. 69 Copyright @ 2026 MariaDB Foundation. • the final diff
  74. Share it: MariaDB Ecosystem Hub https://ecohub.mariadb.org/plugins The Ecohub is a

    place to discover MariaDB Server plugins and other ecosystem projects. Built something useful? Don't leave it hidden in your Git repository. • publish the source and documentation • make installation and supported versions clear • add tests • submit it to the ecosystem • submit the server hooks / patches your plugin needs upstream 70 Copyright @ 2026 MariaDB Foundation.
  75. Share it: MariaDB Ecosystem Hub https://ecohub.mariadb.org/plugins The Ecohub is a

    place to discover MariaDB Server plugins and other ecosystem projects. Built something useful? Don't leave it hidden in your Git repository. Your very local plugin may solve somebody else's very local problem. • publish the source and documentation • make installation and supported versions clear • add tests • submit it to the ecosystem • submit the server hooks / patches your plugin needs upstream 70 Copyright @ 2026 MariaDB Foundation.
  76. The bigger opportunity Plugins tell us where MariaDB is extensible.

    Plugin pain tells us where MariaDB needs new hooks. When an idea requires a core patch, ask: • is this feature broadly useful? • or is a reusable service / hook missing? A better extension point can unlock many future plugins. 72 Copyright @ 2026 MariaDB Foundation.
  77. What's next? Maybe the creation of a catalog that will

    allow easy installation from the client? 73 Copyright @ 2026 MariaDB Foundation.
  78. Takeaways 1. MariaDB Server is an extensible platform. 2. SQL

    function plugins are an excellent entry point. 3. Plugins can expose internals, change behavior and encode domain rules. 4. MTR makes plugin experiments testable like server features. 5. AI coding agents can accelerate review, tests and implementation — progressively. 6. Keep AI provenance in AI_CHANGES.md and review the final diff yourself. 7. Share plugins on the MariaDB Ecosystem Hub and upstream useful extension hooks. 8. For many local needs, a plugin is dramatically easier to own than a fork. 75 Copyright @ 2026 MariaDB Foundation.
  79. Resources • https://github.com/lefred/mariadb-plugin-gtid-info • https://github.com/lefred/mariadb-plugin-disabled-functions • https://github.com/lefred/mariadb-plugin-extra-misc • https://github.com/lefred/mariadb-plugin-inet-more •

    https://github.com/lefred/mariadb-plugin-uuid-more • https://github.com/lefred/mariadb-plugin-func_uuid • https://github.com/lefred/mariadb-plugin-tcmalloc-pro�ler • https://github.com/lefred/mariadb-plugin-type-bce • https://ecohub.mariadb.org/plugins • https://mariadb.com/docs/server/reference/plugins/plugin-overview • https://mariadb.org/adding-a-new-data-type-to-mariadb-with-type_handler-part-0/ • https://mariadb.com/docs/server/reference/sql-functions/secondary-functions/miscellaneous-functions/uuid_v7 • https://mariadb.com/docs/server/reference/product-development/plugin-development/development-writing-plugins-for-mariadb 78 Copyright @ 2026 MariaDB Foundation.