-
Notifications
You must be signed in to change notification settings - Fork 546
/
5.6.2.rst
123 lines (87 loc) · 4.33 KB
/
5.6.2.rst
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
.. _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``