Version 6.5.0 - Unreleased

Note

In development. 6.5.0 isn’t released yet. These are the release notes for the upcoming release.

Note

If you are upgrading a cluster, you must be running CrateDB 5.0.0 or higher before you upgrade to 6.5.0.

We recommend that you upgrade to the latest 6.4 release before moving to 6.5.0.

A rolling upgrade from >= 6.4.0 to 6.5.0 is supported. Before upgrading, you should back up your data.

Warning

Tables that were created before CrateDB 5.x will not function with 6.x and must be recreated before moving to 6.x.x.

You can recreate tables using COPY TO and COPY FROM or by inserting the data into a new table.

Table of contents

Breaking Changes

  • The PostgreSQL type mapping of CrateDB’s byte type changed from "char" (OID 18) to int2 (OID 21). Clients now receive byte columns as int2 in both text and binary formats.

    Most clients reading data determine the type of a column dynamically, and are largely unaffected. With pgjdbc, ResultSet’s getString() and getByte() return the same results as before. getObject() now returns a Short instead of a String.

    The CrateDB JDBC driver is unaffected: getObject() returns an Integer as it did before.

  • Changed the type mapping of PostgreSQL’s "char" type from byte to character(1).

    Before:

    CREATE TABLE tbl (col "char"); was equal to CREATE TABLE tbl (col byte);

    After:

    CREATE TABLE tbl (col "char"); is equal to CREATE TABLE tbl (col character(1));

    Existing tables are not affected. For new tables the character(1) column will reject byte values, which are valid for a byte column:

    INSERT INTO tbl (col) VALUES (65); SQLParseException[‘65’ is too long for the character type of length: 1]

    This improves compatibility with PostgreSQL: In cases where a PostgreSQL client sets the parameter type hint to OID 18 ("char"), and casts the value to character or varchar, the byte encoded "char" value is now correctly interpreted as ASCII decimal 65, resulting in "A". Before it interpreted 65 as a character sequence, resulting in a "65" string.

  • The query plan that EXPLAIN displays no longer shows operands in the order as written in the query. This is because operands are now normalized to be in lexicographic order. This enables deduplication of symmetrical join conditions (i.e. a = b is identical to b = a). Query results are not affected.

Deprecations

None

Changes

SQL Statements

None

SQL Standard and PostgreSQL Compatibility

None

Data Types

  • Dhruv Patel added support for using date as a column type in CREATE TABLE statements, enabling migration of PostgreSQL schemas containing DATE columns without DDL modification.

Scalar and Aggregation Functions

None

Performance and Resilience Improvements

  • Re-added the change to swapping and renaming of tables to no longer re-allocate the shards of the swapped/renamed table, so that in-progress snapshots can finish successfully. Previously, the in-progress snapshots would fail and remain in PARTIAL state, with an ABORTED failure message showing in the sys.snapshots system table.

  • Bing O’Dowd improved query planning by deduplicating identical join conditions joined by the AND operator.

  • Improved the performance of GROUP BY queries on a single STRING column with doc values enabled: aggregation values are now read directly from doc values where possible.

  • Somil Jain improved metadata query performance by caching analyzed ViewInfo instances, reducing repeated analysis of view definitions when accessing information_schema views.

  • Improved DELETE, DROP TABLE, DROP COLUMN, ADD COLUMN, RENAME COLUMN, SET/DROP DEFAULT and DROP CONSTRAINT such that concurrent SWAP TABLE cannot affect aforementioned queries already in progress.

  • Improved RENAME TABLE to fail if the source relation name points to a different table while the statement is being executed.

  • Improved SWAP TABLE to fail if the source or target relation name points to a different table while the statement is being executed.

Administration and Operations

None

Client interfaces

None

SQL Standard and PostgreSQL Compatibility

  • Somil Jain added the information_schema.constraint_column_usage view to improve PostgreSQL compatibility with tools that introspect database metadata.