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 1gP7li-0004c8-A8 for pgsql-docs@arkaria.postgresql.org; Tue, 20 Nov 2018 15:16:50 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gP7lg-0000fa-7w for pgsql-docs@arkaria.postgresql.org; Tue, 20 Nov 2018 15:16:48 +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 1gP7lf-0000fT-Uo for pgsql-docs@lists.postgresql.org; Tue, 20 Nov 2018 15:16:48 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gP7ld-0006Bq-IL for pgsql-docs@lists.postgresql.org; Tue, 20 Nov 2018 15:16:46 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id wAKFGgbd011975; Tue, 20 Nov 2018 10:16:42 -0500 From: Tom Lane To: "Jonathan S. Katz" cc: Bruce Momjian , emilioplatzer@gmail.com, pgsql-docs@lists.postgresql.org, Alvaro Herrera Subject: Re: Documentation for create unique index is insuficient and (because of that) incorrect In-reply-to: References: <154031939560.30897.14677735588262722042@wrigleys.postgresql.org> <20181120020542.GH28656@momjian.us> <9ba37df7-156b-b983-65b5-85ed096818b9@postgresql.org> <11323.1542725958@sss.pgh.pa.us> Comments: In-reply-to "Jonathan S. Katz" message dated "Tue, 20 Nov 2018 10:02:01 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11973.1542727002.1@sss.pgh.pa.us> Date: Tue, 20 Nov 2018 10:16:42 -0500 Message-ID: <11974.1542727002@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk "Jonathan S. Katz" writes: > On 11/20/18 9:59 AM, Tom Lane wrote: >> Yes. That was a dumb idea; the correct fix is to take that out, because >> it's not appropriate here. There might be room for an additional section >> later in the chapter that discusses INCLUDE, but we shouldn't be >> cluttering the discussion of fundamental concepts like unique indexes >> with that. > Shows how closely I read the docs. +1 on removing INCLUDE from UNIQUE > indexes. > > Also +1 on having a section on covering indexes. I see Alvaro is on the same page here. I'll go write something later today. regards, tom lane