Re: [HACKERS] pg_dump emits ALTER TABLE ONLY partitioned_table - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] pg_dump emits ALTER TABLE ONLY partitioned_table
Date
Msg-id CA+Tgmob=xywPTSnok_aObFW7OssZi0VV-ke-MSN4hfaz437_3w@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] pg_dump emits ALTER TABLE ONLY partitioned_table  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Responses Re: [HACKERS] pg_dump emits ALTER TABLE ONLY partitioned_table
List pgsql-hackers
On Wed, Apr 12, 2017 at 6:29 AM, Amit Langote
<Langote_Amit_f8@lab.ntt.co.jp> wrote:
> Actually, p1 is a partitioned table, so the error.  And I realize that
> that's a wrong behavior.  Currently the check is performed using only the
> relkind, which is bogus.  Specifying ONLY should cause an error only when
> the table has partitions.

That sounds like a REALLY bad idea, because now you're going to end up
with a constraint that can never be enforced against any actual data
rows ... or else you're going to later pretend that ONLY wasn't
specified.  I think the rule that partitioned tables can't have
non-inherited constraints is absolutely right, and relaxing it is
quite wrong.

I think you had the right idea upthread when you suggested dumping it this way:

CREATE TABLE p1 PARTITION OF p (   b NOT NULL
)
FOR VALUES IN (1)
PARTITION BY RANGE (b);

That looks absolutely right to me, and very much principled.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: [HACKERS] Some thoughts about SCRAM implementation
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] Some thoughts about SCRAM implementation