Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t8OJz-003uDW-Qt for pgsql-hackers@arkaria.postgresql.org; Tue, 05 Nov 2024 18:30:31 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1t8OJx-00HHhZ-7p for pgsql-hackers@arkaria.postgresql.org; Tue, 05 Nov 2024 18:30:29 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t8OJw-00HHgY-UW for pgsql-hackers@lists.postgresql.org; Tue, 05 Nov 2024 18:30:29 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t8OJu-000LT4-Tn for pgsql-hackers@postgresql.org; Tue, 05 Nov 2024 18:30:28 +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 4A5IUPHn3076357; Tue, 5 Nov 2024 13:30:25 -0500 From: Tom Lane To: Nikolay Samokhvalov cc: Robert Haas , pgsql-hackers@postgresql.org Subject: Re: Proposals for EXPLAIN: rename ANALYZE to EXECUTE and extend VERBOSE In-reply-to: References: Comments: In-reply-to Nikolay Samokhvalov message dated "Tue, 05 Nov 2024 10:24:36 -0800" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3076355.1730831425.1@sss.pgh.pa.us> Date: Tue, 05 Nov 2024 13:30:25 -0500 Message-ID: <3076356.1730831425@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Nikolay Samokhvalov writes: > Let's focus on item 2. Is it really impossible to make VERBOSE really > verbose? It's obviously not "impossible" -- the code changes would likely be trivial. The question is whether it's a good idea. These semantics were (I presume) deliberately chosen when the options were added, so somebody thought not. You would need to go back and review the relevant mail thread and then make arguments why that decision was wrong. In short: we're not working in a green field here, and all these decisions have history. You will not get far by just popping up and saying "I think it should be different". You need to make a case why the decision was wrong, and why it was so wrong that we should risk cross-version-compatibility problems by changing. regards, tom lane