Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cxMdS-0000cq-I4 for pgsql-hackers@arkaria.postgresql.org; Sun, 09 Apr 2017 23:52:46 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1cxMdR-00032o-0t for pgsql-hackers@arkaria.postgresql.org; Sun, 09 Apr 2017 23:52:45 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cxMbu-0000FA-Mn for pgsql-hackers@postgresql.org; Sun, 09 Apr 2017 23:51:10 +0000 Received: from mail-pg0-x22e.google.com ([2607:f8b0:400e:c05::22e]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1cxMbn-0000fe-0n for pgsql-hackers@postgresql.org; Sun, 09 Apr 2017 23:51:09 +0000 Received: by mail-pg0-x22e.google.com with SMTP id g2so95578317pge.3 for ; Sun, 09 Apr 2017 16:51:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leadboat.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=7P5mGhCEDNBEebWk775rxCRcApMg9NblU+7NLMovNl0=; b=XSYiOE9uxlixViFQDV+xOpVc+zfae8A2fClTFNn5miuNR6vtOD7s1XG2+xUJRn8BX1 p990p3qpLAGJV8OkArFn7mePFQzEcY4xpF6zGqvBINqkjJ/N59Zt666xWbFnwtZGbCHE mQ/5N8//OX/ke7KQYU95LkA6F9/I/y8th2bqY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=7P5mGhCEDNBEebWk775rxCRcApMg9NblU+7NLMovNl0=; b=LH3A1hLe/KFj490VSypvzzs74pM0V9cgrb5ngvSvV1jmBQuk1hKWvR7uGK2UD6x5XT 5W1tBFLupx7qnMOW7fOzMQu1GqBl5P5OvFq7tQMhM1Q2jFHnXEF3SdYeCBa4vQhlvREu tkHWNac9iJm/1nSkPw/c3Mv2vDp8vN9jseQp81y2QgvgfJ2KP5SsYZr/P3/pLiBm9PL/ 1K3rTf3Smn//McCPnMqnYv3rJLQj9agfRw2cV3ph4TU+M4PLCA1QHExZLxrU72KN5BBt Q2w+amvNqagQ0I3660Khs3r1nQ1jyI871orOGM1kj92iJ8oXbk8t0XO8pHdPHA4Ji3yg 4wWw== X-Gm-Message-State: AFeK/H3yQyML6Nw248AT82tGplzChqwES0Q/A/iWU3K0nBP+ilS+mRzBVG1k9clROY0WiQ== X-Received: by 10.99.111.204 with SMTP id k195mr36544071pgc.200.1491781861405; Sun, 09 Apr 2017 16:51:01 -0700 (PDT) Received: from tornado.leadboat.com (c-98-248-47-228.hsd1.ca.comcast.net. [98.248.47.228]) by smtp.gmail.com with ESMTPSA id k88sm20716637pfj.79.2017.04.09.16.50.59 (version=TLS1 cipher=AES128-SHA bits=128/128); Sun, 09 Apr 2017 16:51:00 -0700 (PDT) Date: Sun, 9 Apr 2017 23:50:57 +0000 From: Noah Misch To: Robert Haas Cc: Amit Langote , Pg Hackers Subject: Re: pg_dump emits ALTER TABLE ONLY partitioned_table Message-ID: <20170409235057.GA2842536@tornado.leadboat.com> References: <7682253a-6f79-6a92-00aa-267c4c412870@lab.ntt.co.jp> <9599c3b3-87d4-39d1-1f75-d205a726b863@lab.ntt.co.jp> <9c6a9a7d-684f-bb8b-b972-ee20445a9e6d@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9c6a9a7d-684f-bb8b-b972-ee20445a9e6d@lab.ntt.co.jp> User-Agent: Mutt/1.5.24 (2015-08-30) X-Pg-Spam-Score: -2.0 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org On Wed, Mar 29, 2017 at 05:38:41PM +0900, Amit Langote wrote: > On 2017/03/29 0:39, Robert Haas wrote: > > On Tue, Mar 28, 2017 at 6:50 AM, Amit Langote > > wrote: > >>> Isn't it bogus that this is generating ALTER TABLE .. SET NOT NULL > >>> columns at all? You didn't say anything like that when setting up the > >>> database, so why should it be there when dumping? > >> > >> So we should find a way for the NOT NULL constraints added for the range > >> partition key columns to not be emitted *separately*? Like when a table > >> has primary key: > >> > >> -- > >> -- Name: foo; Type: TABLE; Schema: public; Owner: amit > >> -- > >> > >> CREATE TABLE foo ( > >> a integer NOT NULL > >> ); > >> > >> > >> ALTER TABLE foo OWNER TO amit; > >> > >> -- > >> -- Name: foo foo_pkey; Type: CONSTRAINT; Schema: public; Owner: amit > >> -- > >> > >> ALTER TABLE ONLY foo > >> ADD CONSTRAINT foo_pkey PRIMARY KEY (a); > >> > >> The NOT NULL constraint is emitted with CREATE TABLE, not separately. > > > > Hmm, that's not exactly what I was thinking, but I think what I was > > thinking was wrong, so, yes, can we do what you said? > > I thought about this for a while. Although it seems we can do what I said > for (partitioned) tables themselves, it's not real clear to me how > straightforward it is to do for partitions (child tables). Inheritance or > localness of attributes/constraints including NOT NULL dictates whether an > attribute or a constraint is emitted separately. I think that any > additional consideration will make the logic to *not* dump separately (or > perhaps to not emit at all) will become more involved. For example, if a > NOT NULL constraint on a column has been inherited and originated in the > parent from the range partition key, then does it mean we should not emit > it or emit it but not separately? [Action required within three days. This is a generic notification.] The above-described topic is currently a PostgreSQL 10 open item. Robert, since you committed the patch believed to have created it, you own this open item. If some other commit is more relevant or if this does not belong as a v10 open item, please let us know. Otherwise, please observe the policy on open item ownership[1] and send a status update within three calendar days of this message. Include a date for your subsequent status update. Testers may discover new open items at any time, and I want to plan to get them all fixed well in advance of shipping v10. Consequently, I will appreciate your efforts toward speedy resolution. Thanks. [1] https://www.postgresql.org/message-id/20170404140717.GA2675809%40tornado.leadboat.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers