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 1jJL9p-0006Xj-CZ for pgsql-hackers@arkaria.postgresql.org; Tue, 31 Mar 2020 17:58:37 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jJL9n-00088G-52 for pgsql-hackers@arkaria.postgresql.org; Tue, 31 Mar 2020 17:58:35 +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 1jJL9m-000889-U0 for pgsql-hackers@lists.postgresql.org; Tue, 31 Mar 2020 17:58:34 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jJL9j-00052i-M1 for pgsql-hackers@lists.postgresql.org; Tue, 31 Mar 2020 17:58:34 +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 02VHwOwu018989; Tue, 31 Mar 2020 13:58:24 -0400 From: Tom Lane To: James Coleman cc: Alvaro Herrera , Tomas Vondra , Michael Paquier , Rafia Sabih , Peter Geoghegan , Simon Riggs , Shaun Thomas , Dmitry Dolgov <9erthalion6@gmail.com>, Alexander Korotkov , PostgreSQL Developers , Andreas Karlsson Subject: Re: [PATCH] Incremental sort (was: PoC: Partial sort) In-reply-to: References: <20200331163126.GA6532@alvherre.pgsql> <346.1585674268@sss.pgh.pa.us> Comments: In-reply-to James Coleman message dated "Tue, 31 Mar 2020 13:25:02 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <18987.1585677504.1@sss.pgh.pa.us> Date: Tue, 31 Mar 2020 13:58:24 -0400 Message-ID: <18988.1585677504@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk James Coleman writes: > On Tue, Mar 31, 2020 at 1:04 PM Tom Lane wrote: >> Perhaps the semantics are such that that's actually sensible, but it's >> far from a straightforward remapping of the old enum. > Right, I didn't see the explicit "= 0" in other enums there, so it > made me wonder if it was intentional to designate that one had to be > 0, but I guess without a comment that's a lot of inference. It's possible that somebody meant that as an indicator that the code depends on palloc0() leaving the field with that value. But if so, you'd soon find that out ... and an actual comment would be better, anyway. regards, tom lane