










MariaDB Community Server 13.0 GA deepens Oracle PL/SQL compatibility with REF CURSORs and RECORD types, gives developers UPDATE…RETURNING, expands manageability across INFORMATION_SCHEMA and SHOW VARIABLES, extends the new-style optimizer hint framework, and adds InnoDB log archiving for backup and point-in-time recovery.
REF CURSOR types and RECORD in routine parameters and function returns makes it easier to bring Oracle PL/SQL-based applications to MariaDB. UPDATE ... RETURNING lets applications read back changed rows without a follow-up SELECT. INFORMATION_SCHEMA, a visible init_rpl_role variable, and deprecation flags for system variables make auditing and troubleshooting easier. innodb_log_archive preserves InnoDB’s write-ahead log as a sequential history instead of a ring buffer, enabling point-in-time recovery and incremental backups. We are excited to announce the General Availability of MariaDB Community Server 13.0. Building on the foundation laid by the MariaDB Community Server 12.3 LTS, this version pushes further into Oracle compatibility, gives developers a new way to retrieve data from UPDATE statements, and gives DBAs finer-grained tools for observability, query tuning, and backup and recovery.
As part of our quarterly rolling release cycle, MariaDB Community Server 13.0 GA is a rolling release and will not receive further bug-fix releases. We encourage everyone to explore these new capabilities as we continue toward the next Long-Term Support (LTS) release.
Continuing its long-standing investment in Oracle PL/SQL compatibility, MariaDB 13.0 fills in gaps that make it easier to port stored routines and procedural logic from Oracle environments.
SYS_REFCURSOR. Cursor variables declared this way can be opened, fetched from, and closed like other cursors, bringing MariaDB’s cursor handling closer in line with Oracle’s PL/SQL. In 13.0, REF CURSOR can be declared inside package routines and in a PACKAGE BODY, and used as a local variable, package routine parameter, or package function RETURN type; it is not yet supported as a parameter or RETURN type for global (non-package) routines.RECORD type can now be used as the type of stored routine parameters and as the return type of stored functions, not just for local variables. This is also a foundational piece for making REF CURSOR support complete, since routines that return or accept cursors often need to pass structured row types along with them. As with REF CURSOR, this support in 13.0 is scoped to package routines and PACKAGE BODY; RECORD cannot yet be used as a parameter or RETURN type for global (non-package) routines.MariaDB 13.0 also gives application developers a more direct way to work with data changed by DML statements.
UPDATE statements can now include a RETURNING clause, returning a result set of the affected rows directly from the UPDATE itself. Combined with the OLD_VALUE() function, applications can retrieve both the pre- and post-update values of changed columns in one round trip, without issuing a separate SELECT. This joins the existing RETURNING support for INSERT and single-table DELETE, rounding out the set of DML statements that can hand back data to the client. Note that RETURNING is only supported for single-table updates; multi-table UPDATE does not support it yet.MariaDB 13.0 gives administrators clearer, more queryable insight into server configuration and schema metadata.
--init-rpl-role startup option is now exposed as a proper system variable, queryable with SHOW VARIABLES LIKE 'init_rpl_role' or SELECT @@init_rpl_role. Previously this setting could only be inspected by checking the server’s configuration file, making it harder to confirm a running server’s replication role at a glance.CREATE_OPTIONS column, surfacing storage-engine-specific options for indexes and columns that were previously only visible via SHOW CREATE TABLE. This makes it much easier to inspect and audit engine-specific metadata programmatically.The new-style optimizer hint framework, introduced in MariaDB 12.0 and 12.1, continues to mature.
ib_logfile0), InnoDB writes a continuous, sequentially-named series of log files, retiring each one to read-only once a checkpoint completes in the next. This preserves a full history of the write-ahead log for as long as archiving is enabled, enabling point-in-time recovery to a specific Log Sequence Number (LSN) and supporting incremental backup strategies that were not previously possible with the ring-buffer model. This is particularly useful for InnoDB-only deployments or recovery scenarios where binary logs are not available or enabled. Note that as of this release, mariadb-backup does not yet support the innodb_log_archive=ON log format.MariaDB Community Server 13.0 GA is now available as part of our rolling release cycle. This model ensures that new features and enhancements reach the community faster. As we continue these quarterly updates leading toward our next Long-Term Support (LTS) version (13.3), we invite you to test these latest capabilities in your environments.
Download MariaDB Community Server 13.0 GA here.
此内容由惯性聚合(RSS阅读器)自动聚合整理,仅供阅读参考。 原文来自 — 版权归原作者所有。