Обсуждение: Postgres 11: Table Partitioning and Primary Keys

The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/11/ddl-partitioning.html
Description:

In the documentation for Postgres 11 table partitioning, there is no mention
of the requirement that the Primary Key of a partitioned table must contain
the partition key.
In fact the documentation on primary keys is so light that I am not even
100% sure the above is correct.  If the following table is not possible in
Postgres 11, the documentation should find some way to make that clear.  

-- Create partitioned table with partition key not in primary key 
create table events (
                id bigint not null default nextval('events_id_seq'),
                created_date timestamp not null,
                constraint events_pk primary key (id)
) partition by range (created_date);
-- end create table

I believe this should be documented in section "5.10.2.3. Limitations"

On Fri, Jul  5, 2019 at 09:20:07PM +0000, PG Doc comments form wrote:
> The following documentation comment has been logged on the website:
> 
> Page: https://www.postgresql.org/docs/11/ddl-partitioning.html
> Description:
> 
> In the documentation for Postgres 11 table partitioning, there is no mention
> of the requirement that the Primary Key of a partitioned table must contain
> the partition key.
> In fact the documentation on primary keys is so light that I am not even
> 100% sure the above is correct.  If the following table is not possible in
> Postgres 11, the documentation should find some way to make that clear.  
> 
> -- Create partitioned table with partition key not in primary key 
> create table events (
>                 id bigint not null default nextval('events_id_seq'),
>                 created_date timestamp not null,
>                 constraint events_pk primary key (id)
> ) partition by range (created_date);
> -- end create table
> 
> I believe this should be documented in section "5.10.2.3. Limitations"

Can someone comment on this?  CC to hackers.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

On Fri, Jul  5, 2019 at 09:20:07PM +0000, PG Doc comments form wrote:
> The following documentation comment has been logged on the website:
> 
> Page: https://www.postgresql.org/docs/11/ddl-partitioning.html
> Description:
> 
> In the documentation for Postgres 11 table partitioning, there is no mention
> of the requirement that the Primary Key of a partitioned table must contain
> the partition key.
> In fact the documentation on primary keys is so light that I am not even
> 100% sure the above is correct.  If the following table is not possible in
> Postgres 11, the documentation should find some way to make that clear.  
> 
> -- Create partitioned table with partition key not in primary key 
> create table events (
>                 id bigint not null default nextval('events_id_seq'),
>                 created_date timestamp not null,
>                 constraint events_pk primary key (id)
> ) partition by range (created_date);
> -- end create table
> 
> I believe this should be documented in section "5.10.2.3. Limitations"

Can someone comment on this?  CC to hackers.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

On Mon, Jul 08, 2019 at 10:37:37PM -0400, Bruce Momjian wrote:
> On Fri, Jul  5, 2019 at 09:20:07PM +0000, PG Doc comments form wrote:
>> In the documentation for Postgres 11 table partitioning, there is no mention
>> of the requirement that the Primary Key of a partitioned table must contain
>> the partition key.
>> In fact the documentation on primary keys is so light that I am not even
>> 100% sure the above is correct.  If the following table is not possible in
>> Postgres 11, the documentation should find some way to make that clear.
>>
>> I believe this should be documented in section "5.10.2.3. Limitations"
>
> Can someone comment on this?  CC to hackers.

Yep, that's the case:
=# CREATE TABLE parent_tab (id int, id2 int primary key)
     PARTITION BY RANGE (id);
ERROR:  0A000: insufficient columns in PRIMARY KEY constraint
definition
DETAIL:  PRIMARY KEY constraint on table "parent_tab" lacks column
"id" which is part of the partition key.
LOCATION:  DefineIndex, indexcmds.c:894

I agree with the report here that adding one sentence to 5.10.2.3
which is for the limitations of declarative partitioning would be a
good idea.  We don't mention the limitation in CREATE TABLE either
(which would be rather incorrect IMO).

Attached is an idea of patch for the documentation, using this
wording:
+     <listitem>
+      <para>
+       When defining a primary key on a partitioned table, the primary
+       key column must be included in the partition key.
+      </para>
+     </listitem>
If somebody has any better idea for that paragraph, please feel free.
--
Michael

On Mon, Jul 08, 2019 at 10:37:37PM -0400, Bruce Momjian wrote:
> On Fri, Jul  5, 2019 at 09:20:07PM +0000, PG Doc comments form wrote:
>> In the documentation for Postgres 11 table partitioning, there is no mention
>> of the requirement that the Primary Key of a partitioned table must contain
>> the partition key.
>> In fact the documentation on primary keys is so light that I am not even
>> 100% sure the above is correct.  If the following table is not possible in
>> Postgres 11, the documentation should find some way to make that clear.
>>
>> I believe this should be documented in section "5.10.2.3. Limitations"
>
> Can someone comment on this?  CC to hackers.

Yep, that's the case:
=# CREATE TABLE parent_tab (id int, id2 int primary key)
     PARTITION BY RANGE (id);
ERROR:  0A000: insufficient columns in PRIMARY KEY constraint
definition
DETAIL:  PRIMARY KEY constraint on table "parent_tab" lacks column
"id" which is part of the partition key.
LOCATION:  DefineIndex, indexcmds.c:894

I agree with the report here that adding one sentence to 5.10.2.3
which is for the limitations of declarative partitioning would be a
good idea.  We don't mention the limitation in CREATE TABLE either
(which would be rather incorrect IMO).

Attached is an idea of patch for the documentation, using this
wording:
+     <listitem>
+      <para>
+       When defining a primary key on a partitioned table, the primary
+       key column must be included in the partition key.
+      </para>
+     </listitem>
If somebody has any better idea for that paragraph, please feel free.
--
Michael

Michael Paquier <michael@paquier.xyz> writes:
> Attached is an idea of patch for the documentation, using this
> wording:
> +     <listitem>
> +      <para>
> +       When defining a primary key on a partitioned table, the primary
> +       key column must be included in the partition key.
> +      </para>
> +     </listitem>

Isn't it the other way around, that the partition key column(s) must be
included in the primary key?  Maybe I'm confused, but it seems like
we couldn't enforce PK uniqueness otherwise.

            regards, tom lane

Michael Paquier <michael@paquier.xyz> writes:
> Attached is an idea of patch for the documentation, using this
> wording:
> +     <listitem>
> +      <para>
> +       When defining a primary key on a partitioned table, the primary
> +       key column must be included in the partition key.
> +      </para>
> +     </listitem>

Isn't it the other way around, that the partition key column(s) must be
included in the primary key?  Maybe I'm confused, but it seems like
we couldn't enforce PK uniqueness otherwise.

            regards, tom lane

On Mon, Jul 08, 2019 at 08:12:18PM -0700, David G. Johnston wrote:
> Reads a bit backward.  How about:
>
> "As uniqueness can only be enforced within an individual partition when
> defining a primary key on a partitioned table all columns present in the
> partition key must also exist in the primary key."

Yes, I was not really inspired on this one.

Looking closely at the code in DefineIndex() (and as Rajkumar has
mentioned upthread for unique constraints) this can happen for primary
keys, unique constraints and exclusion constraints.  So we had better
mention all three of them.  I am not sure that we need to be explicit
about the uniqueness part though, let's say the following:
"When defining a primary key, a unique constraint or an exclusion
constraint on a partitioned table, all the columns present in the
constraint definition must be included in the partition key."
--
Michael

On Mon, Jul 08, 2019 at 08:12:18PM -0700, David G. Johnston wrote:
> Reads a bit backward.  How about:
>
> "As uniqueness can only be enforced within an individual partition when
> defining a primary key on a partitioned table all columns present in the
> partition key must also exist in the primary key."

Yes, I was not really inspired on this one.

Looking closely at the code in DefineIndex() (and as Rajkumar has
mentioned upthread for unique constraints) this can happen for primary
keys, unique constraints and exclusion constraints.  So we had better
mention all three of them.  I am not sure that we need to be explicit
about the uniqueness part though, let's say the following:
"When defining a primary key, a unique constraint or an exclusion
constraint on a partitioned table, all the columns present in the
constraint definition must be included in the partition key."
--
Michael

On Mon, Jul 08, 2019 at 11:10:51PM -0400, Tom Lane wrote:
> Isn't it the other way around, that the partition key column(s) must
> be
> included in the primary key?  Maybe I'm confused, but it seems like
> we couldn't enforce PK uniqueness otherwise.

Yes you are right.  The full column list of the partition key needs to
be included in the constraint, but that's not true the other way
around.
--
Michael

On Mon, Jul 08, 2019 at 11:10:51PM -0400, Tom Lane wrote:
> Isn't it the other way around, that the partition key column(s) must
> be
> included in the primary key?  Maybe I'm confused, but it seems like
> we couldn't enforce PK uniqueness otherwise.

Yes you are right.  The full column list of the partition key needs to
be included in the constraint, but that's not true the other way
around.
--
Michael

On Tue, Jul 09, 2019 at 03:34:48PM +0900, Michael Paquier wrote:
> Looking closely at the code in DefineIndex() (and as Rajkumar has
> mentioned upthread for unique constraints) this can happen for primary
> keys, unique constraints and exclusion constraints.  So we had better
> mention all three of them.  I am not sure that we need to be explicit
> about the uniqueness part though, let's say the following:
> "When defining a primary key, a unique constraint or an exclusion
> constraint on a partitioned table, all the columns present in the
> constraint definition must be included in the partition key."

Let's try again that (that's a long day..):
"When defining a primary key, a unique constraint or an exclusion
constraint on a partitioned table, all the columns present in the
partition key must be included in the constraint definition."
--
Michael

On Tue, Jul 09, 2019 at 03:34:48PM +0900, Michael Paquier wrote:
> Looking closely at the code in DefineIndex() (and as Rajkumar has
> mentioned upthread for unique constraints) this can happen for primary
> keys, unique constraints and exclusion constraints.  So we had better
> mention all three of them.  I am not sure that we need to be explicit
> about the uniqueness part though, let's say the following:
> "When defining a primary key, a unique constraint or an exclusion
> constraint on a partitioned table, all the columns present in the
> constraint definition must be included in the partition key."

Let's try again that (that's a long day..):
"When defining a primary key, a unique constraint or an exclusion
constraint on a partitioned table, all the columns present in the
partition key must be included in the constraint definition."
--
Michael

Sorry for jumping in late here.

On Tue, Jul 9, 2019 at 3:51 PM Michael Paquier <michael@paquier.xyz> wrote:
> On Tue, Jul 09, 2019 at 03:34:48PM +0900, Michael Paquier wrote:
> > Looking closely at the code in DefineIndex() (and as Rajkumar has
> > mentioned upthread for unique constraints) this can happen for primary
> > keys, unique constraints and exclusion constraints.  So we had better
> > mention all three of them.  I am not sure that we need to be explicit
> > about the uniqueness part though, let's say the following:
> > "When defining a primary key, a unique constraint or an exclusion
> > constraint on a partitioned table, all the columns present in the
> > constraint definition must be included in the partition key."
>
> Let's try again that (that's a long day..):
> "When defining a primary key, a unique constraint or an exclusion
> constraint on a partitioned table, all the columns present in the
> partition key must be included in the constraint definition."

As mentioned in the docs, defining exclusion constraints on
partitioned tables is not supported.

-- on 13dev
create table p (a int, exclude using gist (a with &&)) partition by list (a);
ERROR:  exclusion constraints are not supported on partitioned tables

Regarding primary key and unique constraints, how about writing it
such that it's clear that there are limitations?  Maybe like:

"While defining a primary key and unique constraints on partitioned
tables is supported, the set of columns being constrained must include
all of the partition key columns."

Maybe, as David also says, it might be a good idea to mention the
reason why.  So maybe like:

"While defining a primary key and unique constraints on partitioned
tables is supported, the set of columns being constrained must include
all of the partition key columns.  This limitation exists because
<productname>PostgreSQL</productname> can ensure uniqueness only
across a given partition."

Thanks,
Amit

[1] https://www.postgresql.org/docs/12/ddl-partitioning.html#DDL-PARTITIONING-DECLARATIVE
5.11.2.3. Limitations
The following limitations apply to partitioned tables:
* There is no way to create an exclusion constraint spanning all
partitions; it is only possible to constrain each leaf partition
individually.

Sorry for jumping in late here.

On Tue, Jul 9, 2019 at 3:51 PM Michael Paquier <michael@paquier.xyz> wrote:
> On Tue, Jul 09, 2019 at 03:34:48PM +0900, Michael Paquier wrote:
> > Looking closely at the code in DefineIndex() (and as Rajkumar has
> > mentioned upthread for unique constraints) this can happen for primary
> > keys, unique constraints and exclusion constraints.  So we had better
> > mention all three of them.  I am not sure that we need to be explicit
> > about the uniqueness part though, let's say the following:
> > "When defining a primary key, a unique constraint or an exclusion
> > constraint on a partitioned table, all the columns present in the
> > constraint definition must be included in the partition key."
>
> Let's try again that (that's a long day..):
> "When defining a primary key, a unique constraint or an exclusion
> constraint on a partitioned table, all the columns present in the
> partition key must be included in the constraint definition."

As mentioned in the docs, defining exclusion constraints on
partitioned tables is not supported.

-- on 13dev
create table p (a int, exclude using gist (a with &&)) partition by list (a);
ERROR:  exclusion constraints are not supported on partitioned tables

Regarding primary key and unique constraints, how about writing it
such that it's clear that there are limitations?  Maybe like:

"While defining a primary key and unique constraints on partitioned
tables is supported, the set of columns being constrained must include
all of the partition key columns."

Maybe, as David also says, it might be a good idea to mention the
reason why.  So maybe like:

"While defining a primary key and unique constraints on partitioned
tables is supported, the set of columns being constrained must include
all of the partition key columns.  This limitation exists because
<productname>PostgreSQL</productname> can ensure uniqueness only
across a given partition."

Thanks,
Amit

[1] https://www.postgresql.org/docs/12/ddl-partitioning.html#DDL-PARTITIONING-DECLARATIVE
5.11.2.3. Limitations
The following limitations apply to partitioned tables:
* There is no way to create an exclusion constraint spanning all
partitions; it is only possible to constrain each leaf partition
individually.

On 2019-Jul-09, Amit Langote wrote:

> As mentioned in the docs, defining exclusion constraints on
> partitioned tables is not supported.

Right.

> "While defining a primary key and unique constraints on partitioned
> tables is supported, the set of columns being constrained must include
> all of the partition key columns.  This limitation exists because
> <productname>PostgreSQL</productname> can ensure uniqueness only
> across a given partition."

I feel that PKs are mostly a special case of UNIQUE keys, so I tend to
mention UNIQUE as the central element and let PKs fall out from that.
That's a mild personal preference only though.  Anyway, based on your
proposed wording, I wrote this:

     <listitem>
      <para>
       Unique constraints on partitioned tables (as well as primary keys)
       must constrain all the partition key columns.  This limitation exists
       because <productname>PostgreSQL</productname> can only enforce
       uniqueness in each partition individually.
      </para>
     </listitem>

I'm not really sure about the "must constrain" verbiage.  Is that really
comprehensible?  Also, I chose to place it just above the existing para
that mentions FK limitations, which reads:

     <listitem>
      <para>
       While primary keys are supported on partitioned tables, foreign
       keys referencing partitioned tables are not supported.  (Foreign key
       references from a partitioned table to some other table are supported.)
      </para>

Your proposed wording seemed to use too many of the same words, which
prompted me to change a bit.  Maybe I read too many novels and
insufficient technical literature.

In CREATE TABLE, we already have this:
     <para>
      When establishing a unique constraint for a multi-level partition
      hierarchy, all the columns in the partition key of the target
      partitioned table, as well as those of all its descendant partitioned
      tables, must be included in the constraint definition.
     </para>

which may not be the pinnacle of clarity, but took some time to craft
and I think is correct.  Also it doesn't mention primary keys
explicitly; maybe we should patch it by adding "(as well as a primary
key)" right after "a unique constraint".  Thoughts?

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On 2019-Jul-09, Amit Langote wrote:

> As mentioned in the docs, defining exclusion constraints on
> partitioned tables is not supported.

Right.

> "While defining a primary key and unique constraints on partitioned
> tables is supported, the set of columns being constrained must include
> all of the partition key columns.  This limitation exists because
> <productname>PostgreSQL</productname> can ensure uniqueness only
> across a given partition."

I feel that PKs are mostly a special case of UNIQUE keys, so I tend to
mention UNIQUE as the central element and let PKs fall out from that.
That's a mild personal preference only though.  Anyway, based on your
proposed wording, I wrote this:

     <listitem>
      <para>
       Unique constraints on partitioned tables (as well as primary keys)
       must constrain all the partition key columns.  This limitation exists
       because <productname>PostgreSQL</productname> can only enforce
       uniqueness in each partition individually.
      </para>
     </listitem>

I'm not really sure about the "must constrain" verbiage.  Is that really
comprehensible?  Also, I chose to place it just above the existing para
that mentions FK limitations, which reads:

     <listitem>
      <para>
       While primary keys are supported on partitioned tables, foreign
       keys referencing partitioned tables are not supported.  (Foreign key
       references from a partitioned table to some other table are supported.)
      </para>

Your proposed wording seemed to use too many of the same words, which
prompted me to change a bit.  Maybe I read too many novels and
insufficient technical literature.

In CREATE TABLE, we already have this:
     <para>
      When establishing a unique constraint for a multi-level partition
      hierarchy, all the columns in the partition key of the target
      partitioned table, as well as those of all its descendant partitioned
      tables, must be included in the constraint definition.
     </para>

which may not be the pinnacle of clarity, but took some time to craft
and I think is correct.  Also it doesn't mention primary keys
explicitly; maybe we should patch it by adding "(as well as a primary
key)" right after "a unique constraint".  Thoughts?

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> That's a mild personal preference only though.  Anyway, based on your
> proposed wording, I wrote this:

>      <listitem>
>       <para>
>        Unique constraints on partitioned tables (as well as primary keys)
>        must constrain all the partition key columns.  This limitation exists
>        because <productname>PostgreSQL</productname> can only enforce
>        uniqueness in each partition individually.
>       </para>
>      </listitem>

> I'm not really sure about the "must constrain" verbiage.  Is that really
> comprehensible?

I think "must include" might be better.

> In CREATE TABLE, we already have this:
>      <para>
>       When establishing a unique constraint for a multi-level partition
>       hierarchy, all the columns in the partition key of the target
>       partitioned table, as well as those of all its descendant partitioned
>       tables, must be included in the constraint definition.
>      </para>

> which may not be the pinnacle of clarity, but took some time to craft
> and I think is correct.  Also it doesn't mention primary keys
> explicitly; maybe we should patch it by adding "(as well as a primary
> key)" right after "a unique constraint".  Thoughts?

I'd leave that alone.  I don't think the parenthetical comment about
primary keys in your new text is adding much either.

            regards, tom lane

Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> That's a mild personal preference only though.  Anyway, based on your
> proposed wording, I wrote this:

>      <listitem>
>       <para>
>        Unique constraints on partitioned tables (as well as primary keys)
>        must constrain all the partition key columns.  This limitation exists
>        because <productname>PostgreSQL</productname> can only enforce
>        uniqueness in each partition individually.
>       </para>
>      </listitem>

> I'm not really sure about the "must constrain" verbiage.  Is that really
> comprehensible?

I think "must include" might be better.

> In CREATE TABLE, we already have this:
>      <para>
>       When establishing a unique constraint for a multi-level partition
>       hierarchy, all the columns in the partition key of the target
>       partitioned table, as well as those of all its descendant partitioned
>       tables, must be included in the constraint definition.
>      </para>

> which may not be the pinnacle of clarity, but took some time to craft
> and I think is correct.  Also it doesn't mention primary keys
> explicitly; maybe we should patch it by adding "(as well as a primary
> key)" right after "a unique constraint".  Thoughts?

I'd leave that alone.  I don't think the parenthetical comment about
primary keys in your new text is adding much either.

            regards, tom lane

On Wed, Jul 10, 2019 at 7:53 AM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> On 2019-Jul-09, Amit Langote wrote:
> > "While defining a primary key and unique constraints on partitioned
> > tables is supported, the set of columns being constrained must include
> > all of the partition key columns.  This limitation exists because
> > <productname>PostgreSQL</productname> can ensure uniqueness only
> > across a given partition."
>
> I feel that PKs are mostly a special case of UNIQUE keys, so I tend to
> mention UNIQUE as the central element and let PKs fall out from that.
> That's a mild personal preference only though.  Anyway, based on your
> proposed wording, I wrote this:
>
>      <listitem>
>       <para>
>        Unique constraints on partitioned tables (as well as primary keys)
>        must constrain all the partition key columns.  This limitation exists
>        because <productname>PostgreSQL</productname> can only enforce
>        uniqueness in each partition individually.
>       </para>
>      </listitem>
>
> I'm not really sure about the "must constrain" verbiage.  Is that really
> comprehensible?

Looks good after replacing "must constraint" by "must include" as
suggested by Tom.

> Also, I chose to place it just above the existing para
> that mentions FK limitations

This placement of the new text sounds good.

> In CREATE TABLE, we already have this:
>      <para>
>       When establishing a unique constraint for a multi-level partition
>       hierarchy, all the columns in the partition key of the target
>       partitioned table, as well as those of all its descendant partitioned
>       tables, must be included in the constraint definition.
>      </para>
>
> which may not be the pinnacle of clarity, but took some time to craft
> and I think is correct.  Also it doesn't mention primary keys
> explicitly; maybe we should patch it by adding "(as well as a primary
> key)" right after "a unique constraint".  Thoughts?

Works for me.

Thanks,
Amit

On Wed, Jul 10, 2019 at 7:53 AM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> On 2019-Jul-09, Amit Langote wrote:
> > "While defining a primary key and unique constraints on partitioned
> > tables is supported, the set of columns being constrained must include
> > all of the partition key columns.  This limitation exists because
> > <productname>PostgreSQL</productname> can ensure uniqueness only
> > across a given partition."
>
> I feel that PKs are mostly a special case of UNIQUE keys, so I tend to
> mention UNIQUE as the central element and let PKs fall out from that.
> That's a mild personal preference only though.  Anyway, based on your
> proposed wording, I wrote this:
>
>      <listitem>
>       <para>
>        Unique constraints on partitioned tables (as well as primary keys)
>        must constrain all the partition key columns.  This limitation exists
>        because <productname>PostgreSQL</productname> can only enforce
>        uniqueness in each partition individually.
>       </para>
>      </listitem>
>
> I'm not really sure about the "must constrain" verbiage.  Is that really
> comprehensible?

Looks good after replacing "must constraint" by "must include" as
suggested by Tom.

> Also, I chose to place it just above the existing para
> that mentions FK limitations

This placement of the new text sounds good.

> In CREATE TABLE, we already have this:
>      <para>
>       When establishing a unique constraint for a multi-level partition
>       hierarchy, all the columns in the partition key of the target
>       partitioned table, as well as those of all its descendant partitioned
>       tables, must be included in the constraint definition.
>      </para>
>
> which may not be the pinnacle of clarity, but took some time to craft
> and I think is correct.  Also it doesn't mention primary keys
> explicitly; maybe we should patch it by adding "(as well as a primary
> key)" right after "a unique constraint".  Thoughts?

Works for me.

Thanks,
Amit

On Tue, Jul 09, 2019 at 06:59:59PM -0400, Tom Lane wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
>>      <listitem>
>>       <para>
>>        Unique constraints on partitioned tables (as well as primary keys)
>>        must constrain all the partition key columns.  This limitation exists
>>        because <productname>PostgreSQL</productname> can only enforce
>>        uniqueness in each partition individually.
>>       </para>
>>      </listitem>
>
>> I'm not really sure about the "must constrain" verbiage.  Is that really
>> comprehensible?
>
> I think "must include" might be better.

+1.

>> which may not be the pinnacle of clarity, but took some time to craft
>> and I think is correct.  Also it doesn't mention primary keys
>> explicitly; maybe we should patch it by adding "(as well as a primary
>> key)" right after "a unique constraint".  Thoughts?
>
> I'd leave that alone.  I don't think the parenthetical comment about
> primary keys in your new text is adding much either.

Agreed with not bothering about this block and not adding the
parenthetical comment.
--
Michael

On Tue, Jul 09, 2019 at 06:59:59PM -0400, Tom Lane wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
>>      <listitem>
>>       <para>
>>        Unique constraints on partitioned tables (as well as primary keys)
>>        must constrain all the partition key columns.  This limitation exists
>>        because <productname>PostgreSQL</productname> can only enforce
>>        uniqueness in each partition individually.
>>       </para>
>>      </listitem>
>
>> I'm not really sure about the "must constrain" verbiage.  Is that really
>> comprehensible?
>
> I think "must include" might be better.

+1.

>> which may not be the pinnacle of clarity, but took some time to craft
>> and I think is correct.  Also it doesn't mention primary keys
>> explicitly; maybe we should patch it by adding "(as well as a primary
>> key)" right after "a unique constraint".  Thoughts?
>
> I'd leave that alone.  I don't think the parenthetical comment about
> primary keys in your new text is adding much either.

Agreed with not bothering about this block and not adding the
parenthetical comment.
--
Michael