Many thanks for reading through it!
David G. Johnston wrote:
> I found the following change to be confusing.
[...]
> I was expecting the doc for ADD CONSTRAINT USING INDEX to note the
> limitation explicitly - in lieu of the above paragraph.
Agreed. I moved the note to ADD CONSTRAINT and added a different on to
ADD CONSTRAINT USING INDEX.
> Also, I cannot reason out what the following limitation means:
>
> /doc/src/sgml/ref/create_table.sgml
> + If any partitions are in turn partitioned, all columns of each
> partition
> + key are considered at each level below the <literal>UNIQUE</literal>
> + constraint.
I can see that being unclear. I tried to be very concise, to avoid
spending too many words on what is mostly a fringe feature; but that
probably didn't work very well. Wording suggestions welcome. What this
means is that if you create a partition that is partitioned on a column
different from its parent, then a primary key that covers the whole
hierarchy (i.e. you're not just adding a PK to the partitioned
partition) must include all partition columns, not just the upper one.
Example:
create table t (a int, b int) partition by range (a);
create table t_1 partition of t for values from (0) to (1000) partition by range (b);
then you may create a unique or PK constraint on t only if you include
both columns (a,b). You may not create a PK on t (a), which is a bit
surprising since (b) is not part of the partition key of t directly,
only of t_1.
Of course, if you create a unique constraint on t_1 (i.e. it doesn't
cover all of t) then you may use (b) alone -- that's what "each level
below the UNIQUE constraint" supposed to convey.
I have trouble coming up with a real-world example where you would run
into this limitation in practice.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services