From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | "Shinoda, Noriyoshi" <noriyoshi(dot)shinoda(at)hpe(dot)com> |
Cc: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Jaime Casanova <jaime(dot)casanova(at)2ndquadrant(dot)com>, Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: unique indexes on partitioned tables |
Date: | 2018-03-08 15:29:01 |
Message-ID: | 20180308152901.p3qxrjnty3tpoqk6@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
Shinoda, Noriyoshi wrote:
> I tried this feature with the latest snapshot. When I executed the
> following SQL statement, multiple primary keys were created on the
> partition. Is this the intended behavior?
Hahah. Is that a serious question? Of course it isn't. I'll fix it:
> -- test
> postgres=> CREATE TABLE part1(c1 INT PRIMARY KEY, c2 INT, c3 VARCHAR(10)) PARTITION BY RANGE(c1) ;
> CREATE TABLE
> postgres=> CREATE TABLE part1v1 (LIKE part1) ;
> CREATE TABLE
> postgres=> ALTER TABLE part1v1 ADD CONSTRAINT pk_part1v1 PRIMARY KEY (c1, c2) ;
> ALTER TABLE
> postgres=> ALTER TABLE part1 ATTACH PARTITION part1v1 FOR VALUES FROM (100) TO (200) ;
> ALTER TABLE
I think the correct behavior here is to error out the ATTACH PARTITION
indicating that a primary key already exist.
Thanks for pointing this out. Please keep testing,
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-03-08 15:29:39 | Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key |
Previous Message | Tom Lane | 2018-03-08 15:07:15 | Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key |