Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nhu3K-0000YU-7y for pgsql-hackers@arkaria.postgresql.org; Fri, 22 Apr 2022 14:14:30 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nhu3I-0003IU-Qw for pgsql-hackers@arkaria.postgresql.org; Fri, 22 Apr 2022 14:14:28 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nhu3I-0003IL-HU for pgsql-hackers@lists.postgresql.org; Fri, 22 Apr 2022 14:14:28 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nhu3G-0000fW-Bf for pgsql-hackers@postgresql.org; Fri, 22 Apr 2022 14:14:27 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 23MEENfZ3688376; Fri, 22 Apr 2022 10:14:23 -0400 From: Tom Lane To: Peter Eisentraut cc: Simon Riggs , "David G. Johnston" , PostgreSQL Hackers Subject: Re: Dump/Restore of non-default PKs In-reply-to: <29672d7c-7000-2467-a99b-33a9a79d55ea@enterprisedb.com> References: <2379840.1650314887@sss.pgh.pa.us> <62224288-cbc0-a759-4ff6-40baa32943eb@enterprisedb.com> <29672d7c-7000-2467-a99b-33a9a79d55ea@enterprisedb.com> Comments: In-reply-to Peter Eisentraut message dated "Fri, 22 Apr 2022 15:38:35 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3688374.1650636863.1@sss.pgh.pa.us> Date: Fri, 22 Apr 2022 10:14:23 -0400 Message-ID: <3688375.1650636863@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Peter Eisentraut writes: > On 21.04.22 13:43, Simon Riggs wrote: >> Can you explain what you find unattractive about it? > Well, if I want to create a table with a primary key, the established > way is to say "primary key", not to have to assemble it from multiple > pieces. > I think this case is very similar to exclusion constraints, which also > have syntax to specify the index access method. That analogy would be compelling if exclusion constraints were a SQL-standard feature; but they aren't so their clause syntax is fully under our control. The scenario that worries me is that somewhere down the pike, the SQL committee might extend the syntax of PKEY/UNIQUE constraint clauses in a way that breaks our nonstandard extensions of them. However, independently of whether we offer a syntax option or not, it may still simplify pg_dump to make it treat the constraint and the index as independent objects in all cases. regards, tom lane