From: | Robert Haas <rhaas(at)postgresql(dot)org> |
---|---|
To: | pgsql-committers(at)postgresql(dot)org |
Subject: | pgsql: Don't explicitly mark range partitioning columns NOT NULL. |
Date: | 2017-05-18 18:05:59 |
Message-ID: | E1dBPoF-0004to-D5@gemulon.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
Don't explicitly mark range partitioning columns NOT NULL.
This seemed like a good idea originally because there's no way to mark
a range partition as accepting NULL, but that now seems more like a
current limitation than something we want to lock down for all time.
For example, there's a proposal to add the notion of a default
partition which accepts all rows not otherwise routed, which directly
conflicts with the idea that a range-partitioned table should never
allow nulls anywhere. So let's change this while we still can, by
putting the NOT NULL test into the partition constraint instead of
changing the column properties.
Amit Langote and Robert Haas, reviewed by Amit Kapila
Discussion: http://postgr.es/m/8e2dd63d-c6fb-bb74-3c2b-ed6d63629c9d@lab.ntt.co.jp
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/3ec76ff1f2cf52e9b900349957b42d28128b7bc7
Modified Files
--------------
contrib/postgres_fdw/expected/postgres_fdw.out | 4 +-
doc/src/sgml/ref/create_table.sgml | 5 --
src/backend/catalog/partition.c | 71 ++++++++++++++++----------
src/backend/commands/tablecmds.c | 57 +--------------------
src/test/regress/expected/alter_table.out | 7 ---
src/test/regress/expected/create_table.out | 40 +++++----------
src/test/regress/expected/insert.out | 5 +-
src/test/regress/sql/alter_table.sql | 8 ---
src/test/regress/sql/create_table.sql | 5 --
9 files changed, 64 insertions(+), 138 deletions(-)
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2017-05-18 19:22:22 | pgsql: Make slab allocator work on platforms with MAXIMUM_ALIGNOF < siz |
Previous Message | Tom Lane | 2017-05-18 16:13:36 | Re: [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run. |