Re: First draft of PG 17 release notes
Bruce Momjian <bruce@momjian.us>
Commits
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Revert support for ALTER TABLE ... MERGE/SPLIT PARTITION(S) commands
- 3890d90c1508 18.0 cited
-
When creating materialized views, use REFRESH to load data.
- b4da732fd64e 17.0 cited
-
Revert temporal primary keys and foreign keys
- 8aee330af55d 17.0 cited
-
Avoid needless large memcpys in libpq socket writing
- c4ab7da60617 17.0 cited
-
Enhance nbtree ScalarArrayOp execution.
- 5bf748b86bc6 17.0 cited
-
Introduce a non-recursive JSON parser
- 3311ea86edc7 17.0 cited
-
Combine freezing and pruning steps in VACUUM
- 6dbb490261a6 17.0 cited
-
Allow SIGINT to cancel psql database reconnections.
- cafe1056558f 17.0 cited
-
Provide API for streaming relation data.
- b5a9b18cd0bc 17.0 cited
-
Add hash support functions and hash opclass for contrib/ltree.
- 485f0aa85995 17.0 cited
-
Pull up ANY-SUBLINK with the necessary lateral support.
- 9f133763961e 17.0 cited
-
Read WAL directly from WAL buffers.
- 91f2cae7a4e6 17.0 cited
-
Introduce the dynamic shared memory registry.
- 8b2bcf3f287c 17.0 cited
-
Add macros for looping through a List without a ListCell.
- 14dd0f27d7cd 17.0 cited
-
Support +/- infinity in the interval data type.
- 519fc1bd9e9d 17.0 cited
-
Extend ALTER OPERATOR to allow setting more optimization attributes.
- 2b5154beab79 17.0 cited
-
Consider cheap startup paths in add_paths_to_append_rel
- a8a968a8212e 17.0 cited
On Thu, May 9, 2024 at 08:40:00PM +0200, Álvaro Herrera wrote: > On 2024-May-09, Bruce Momjian wrote: > > > However, I don't see it mentioned as a release note item in the commit > > message or mentioned in our docs. I suppose the release note text would > > be: > > > > Removing a PRIMARY KEY will remove the NOT NULL column specification > > > > Previously the NOT NULL specification would be retained. > > > > Do we have agreement that we want this release note item? > > Yes. Maybe we want some others too (especially regarding inheritance, > but also regarding the way we handle the constraints internally), and > maybe in this one we want different wording. How about something like > this: > > Removing a primary key constraint may change the nullability > characteristic of the columns that the primary key covered. > > If explicit not-null constraints exist on the same column, then they > continue to be /known not nullable/; otherwise they become /possibly > nullable/. > > This is largely based on the SQL standard's language of a column > descriptor having a "nullability characteristic", which for columns with > not-null or primary key constraints is "known not null". I don't think > we use those terms anywhere. I hope this isn't too confusing. Yes, it was confusing, partly because it is using wording we don't use, and partly because it is talking about what can go into the column, rather than the visible column restriction NOT NULL. I also think "may" is too imprecise. How about: Removing a primary key will remove a column's NOT NULL constraint if the constraint was added by the primary key Previously such NOT NULL constraints would remain after a primary key was removed. A column-level NOT NULL constraint would not be emoved. Here is the PG 16 output: CREATE TABLE test ( x INT CONSTRAINT test_pkey PRIMARY KEY ); Table "public.test" Column | Type | Collation | Nullable | Default --------+---------+-----------+----------+--------- x | integer | | not null | Indexes: "test_pkey" PRIMARY KEY, btree (x) CREATE TABLE test_with_not_null (x INT NOT NULL CONSTRAINT test_pkey_with_not_null PRIMARY KEY); Table "public.test_with_not_null" Column | Type | Collation | Nullable | Default --------+---------+-----------+----------+--------- x | integer | | not null | Indexes: "test_pkey_with_not_null" PRIMARY KEY, btree (x) ALTER TABLE test DROP CONSTRAINT test_pkey; Table "public.test" Column | Type | Collation | Nullable | Default --------+---------+-----------+----------+--------- --> x | integer | | not null | ALTER TABLE test_with_not_null DROP CONSTRAINT test_pkey_with_not_null; Table "public.test_with_not_null" Column | Type | Collation | Nullable | Default --------+---------+-----------+----------+--------- --> x | integer | | not null | Here is the output in PG 17: CREATE TABLE test ( x INT CONSTRAINT test_pkey PRIMARY KEY ); Table "public.test" Column | Type | Collation | Nullable | Default --------+---------+-----------+----------+--------- x | integer | | not null | Indexes: "test_pkey" PRIMARY KEY, btree (x) CREATE TABLE test_with_not_null (x INT NOT NULL CONSTRAINT test_pkey_with_not_null PRIMARY KEY); Table "public.test_with_not_null" Column | Type | Collation | Nullable | Default --------+---------+-----------+----------+--------- x | integer | | not null | Indexes: "test_pkey_with_not_null" PRIMARY KEY, btree (x) ALTER TABLE test DROP CONSTRAINT test_pkey; Table "public.test" Column | Type | Collation | Nullable | Default --------+---------+-----------+----------+--------- --> x | integer | | | ALTER TABLE test_with_not_null DROP CONSTRAINT test_pkey_with_not_null; Table "public.test_with_not_null" Column | Type | Collation | Nullable | Default --------+---------+-----------+----------+--------- --> x | integer | | not null | Notice that the table without a _column_ NOT NULL removes the NOT NULL designation after removing the primary key only in PG 17. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com Only you can decide what is important to you.