.. _version_5.6.2:

=============
Version 5.6.2
=============

Released on 2024-02-15.

.. NOTE::

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

    We recommend that you upgrade to the latest 5.5 release before moving to
    5.6.2.

    A rolling upgrade from 5.5.x to 5.6.2 is supported.
    Before upgrading, you should `back up your data`_.

.. WARNING::

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

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

.. _back up your data: https://crate.io/docs/crate/reference/en/latest/admin/snapshots.html
.. _inserting the data into a new table: https://crate.io/docs/crate/reference/en/latest/admin/system-information.html#tables-need-to-be-recreated

.. rubric:: Table of contents

.. contents::
   :local:

See the :ref:`version_5.6.0` release notes for a full list of changes in the
5.6 series.

Fixes
=====

- Fixed an issue that would cause no results being returned when filtering on a
  :ref:`PRIMARY KEY <constraints-primary-key>` column, wrapped with a
  :ref:`CAST <sql-type-cast>`, e.g.::

    CREATE TABLE tbl(a INTEGER, PRIMARY KEY(a), b INTEGER);
    INSERT INTO tbl(a) VALUES (1, 11);
    REFRESH TABLE tbl;
    SELECT * FROM tbl WHERE CAST(t.a AS BOOLEAN)= true;

  Same issue, previously, would cause no rows to be updated or deleted, e.g. ::

    UPDATE tbl SET b = b + 1 WHERE CAST(t.a AS BOOLEAN)= true;
    DELETE FROM tbl WHERE CAST(t.a AS BOOLEAN)= true;

- Fixed an issue that can cause errors during a rolling upgrade to >=
  :ref:`version_5.6.0` if one of the following command is executed on relations
  with existing privileges:

  - :ref:`DROP TABLE <drop-table>`
  - :ref:`DROP VIEW <sql-drop-view>`
  - :ref:`RENAME TABLE <sql-alter-table-rename-to>`
  - :ref:`SWAP TABLE <alter_cluster_swap_table>`

  These commands are now rejected until all nodes are upgraded.

- Fixed an issue that caused ``NullPointerException`` to be thrown when
  attempting to rename a table on cluster which has been upgraded from versions
  < :ref:`version_5.6.0` to a version >= :ref:`version_5.6.0`, and there were
  users and privileges defined.

- Fixed :ref:`trim <scalar-trim>`, :ref:`ltrim <scalar-ltrim>`,
  :ref:`rtrim <scalar-rtrim>`, and :ref:`btrim <scalar-btrim>` scalar functions
  to return ``NULL``, instead of the original string, when the ``trimmingText``
  argument is ``NULL``, complying with PostgreSQL behaviour for these functions.

- Fixed a regression introduced in 5.6.0 that caused
  :ref:`concat_ws <scalar-concat-ws>` returning the wrong result when used on a
  column with ``NULL`` values in the WHERE-clause combined with a NOT-predicate.
  An example::

    SELECT * FROM t1 WHERE NOT CONCAT_WS(true, column_with_null_value, false);

- Fixed a bug (present since at least :ref:`version_5.2.0`) where columns cast to
  a numeric type with a non-default precision could return the unscaled value in
  a multi-node cluster

- Fixed an issue that caused ``SELECT`` statements with ``WHERE`` clause having
  ``primary keys`` under ``NOT`` predicate to return invalid results.

- Fixed an issue that caused ``SELECT`` statements with ``WHERE`` clause having
  ``NOT`` predicate whose argument consists of ``NULLABLE`` scalar functions
  with ``NULL`` argument that could evaluate to ``NULL`` to return invalid
  results. An example ::

    SELECT * FROM t WHERE (col % NULL) != 1;

  A ``NULLABLE`` function in this context means a function returning ``NULL``
  if and only if the input is a ``NULL``.

- Fixed a race condition that could lead to ``ShardCollectContext already
  added`` errors when making a query after a table had been idle without any
  accesses for a while.

- Fixed an issue when resolving relations. When resolving an unqualified name
  (no explicit schema), it first exhausted the search path looking for tables
  before moving on to views. Now it will correctly look for both table and view
  in each element of the search path before moving onto the next.

  For example, with a search path set to ``a, b``, a query on ``tbl`` will now
  look for:

  - table ``a.tbl``
  - view ``a.tbl``
  - table ``b.tbl``
  - view ``b.tbl``

  Instead of:

  - table ``a.tbl``
  - table ``b.tbl``
  - view ``a.tbl``
  - view ``b.tbl``
