Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hkyzZ-0004eP-UK for pgsql-hackers@arkaria.postgresql.org; Tue, 09 Jul 2019 22:53:46 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hkyzY-0001zb-K3 for pgsql-hackers@arkaria.postgresql.org; Tue, 09 Jul 2019 22:53:44 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hkyzY-0001zS-3E for pgsql-hackers@lists.postgresql.org; Tue, 09 Jul 2019 22:53:44 +0000 Received: from mail-qt1-x844.google.com ([2607:f8b0:4864:20::844]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hkyzQ-0002bG-Pv for pgsql-hackers@postgresql.org; Tue, 09 Jul 2019 22:53:42 +0000 Received: by mail-qt1-x844.google.com with SMTP id j19so355035qtr.12 for ; Tue, 09 Jul 2019 15:53:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=t8IVjkkBgEipg618CBiGciRTvO/JaDuKTYo4yrPPBdQ=; b=e4DC8DVQAtFwu9GkMd5DCvFE7DzwGbaa8pVW57yAdNsqEzFY5VvsjuWW2rJIFx0bgd 1JZvrykQ/MdhkIcSvI+a60oT2A9Xbx8Dvn3CDrpbkWbBYyZX3C6jjEtbB2E0yEZiDfMV gqGfyhnGLxN009xNftVAAv3ApC9DrKp9UrIHBKwNGKn9uB0F+q9ooUNYYTYJp+3XEm5P U9OitluAa3AiBXY9X/ia4A8laeAlopZdMJ6BFH8mo7CDif2XIS63/LR9YufqO9WqP9ct OvJEs72mjM10NAoQ2zzT0zxnGrFPUIu9juHpa5qZVvgAorTXDGXG5SIZ3UEj3ca28heX Bx3w== 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:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=t8IVjkkBgEipg618CBiGciRTvO/JaDuKTYo4yrPPBdQ=; b=PZL7sJ+rdZC4ovH2XNvSh9oTyGj6lkmvUZXh/Fhu+VIoHEbjV33fBxXaNMKwqB4oRX O2EvownX9QHiQetN4zK7xQlVukje9PCX93RHAJq6Zi+R9UBvenWLPe0dB3Lb6Z+JaO6q 6oNGf2aSb0nB7qN3Aj4iYE+r3EyLUgcH4puArf7FoCh61pYK36gQECXHxzAxq4zyYWS/ M1N2ho6fkJiKUk0AOXpFjG4cQu0qCr0hqfgHyaN6uc1t0Gqju9JSIBsM/mmeDq2r+XUD 7BQRJSWks+bIp8DrBDICfm+KslurKsrHb1mF9PPSY7ZwTWbR0SnjwUq1UxhBwnRtCUTW ssbQ== X-Gm-Message-State: APjAAAVybhef+sun+EVbHGnr3elDfIEtvPQp5Vhd0VHg88Ea0LUomET5 fqb+/0I+3wuc8dtGklpSFuUDdg== X-Google-Smtp-Source: APXvYqyZw8p5Xbg77V3uX3RaxIBhLTI0yCZHcyAYiA5n0+jEq5HQtmR1PJVO2PYZtpg/dcNhIkdPnw== X-Received: by 2002:a0c:ffc5:: with SMTP id h5mr21818570qvv.43.1562712815780; Tue, 09 Jul 2019 15:53:35 -0700 (PDT) Received: from nimloth.alvh.no-ip.org ([190.121.29.3]) by smtp.gmail.com with ESMTPSA id 23sm207250qkk.121.2019.07.09.15.53.35 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Tue, 09 Jul 2019 15:53:35 -0700 (PDT) Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id 7BBED120219; Tue, 9 Jul 2019 18:53:33 -0400 (-04) Date: Tue, 9 Jul 2019 18:53:33 -0400 From: Alvaro Herrera To: Amit Langote Cc: Michael Paquier , "David G. Johnston" , Bruce Momjian , phil.bayer@gmail.com, pgsql-docs@lists.postgresql.org, PostgreSQL-development Subject: Re: Postgres 11: Table Partitioning and Primary Keys Message-ID: <20190709225333.GA18051@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk 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 > PostgreSQL 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: Unique constraints on partitioned tables (as well as primary keys) must constrain all the partition key columns. This limitation exists because PostgreSQL can only enforce uniqueness in each partition individually. 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: 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.) 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: 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. 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