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 1pKxmt-00072B-0B for pgsql-hackers@arkaria.postgresql.org; Thu, 26 Jan 2023 08:39:15 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pKxmr-0000wv-TL for pgsql-hackers@arkaria.postgresql.org; Thu, 26 Jan 2023 08:39:13 +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 1pKxmr-0000wm-Jy for pgsql-hackers@lists.postgresql.org; Thu, 26 Jan 2023 08:39:13 +0000 Received: from wnew4-smtp.messagingengine.com ([64.147.123.18]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pKxmp-0007X2-FV for pgsql-hackers@lists.postgresql.org; Thu, 26 Jan 2023 08:39:13 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailnew.west.internal (Postfix) with ESMTP id 2901B2B06DF3; Thu, 26 Jan 2023 03:39:08 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Thu, 26 Jan 2023 03:39:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1674722347; x= 1674729547; bh=51i9G9M5vz0XqFV1UEWFN2VoCPfvdUq7bgNz9oT/GcI=; b=l 58QUZaThTK5GV5XbNUjbpCvUa3VJwKWU3b6mprj0jmD+SAVuF16Mqt/Ap12rJScB sLbLGH7+BNS9rfGruAoUFxYNOUDjqAn72HluhrDUpdpQM8YbuPGR6bvfSurkC0hV jA0Au3SxwV9TocE50spSC9nYVpvGljm0uqBV/nF7PJZwRcVr1v7Zwru6tV1ITfli A/e1IlS19J1lUAPF0Wrs8Dr9v24G4gh+qogW6jBCOkVIm/V2QZ4dKbuL8A6lhvIY B82YjkzUHStQsc+iGOZgSH1w05C7P4cENu2kRT3VbERsLdTZu4EZJHkc/IG0Jc2N 6uhQSxf2cA/tTa8F/P6sQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedruddvfedguddvvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttdefjeenucfhrhhomheprfgv thgvrhcugfhishgvnhhtrhgruhhtuceophgvthgvrhdrvghishgvnhhtrhgruhhtsegvnh htvghrphhrihhsvggusgdrtghomheqnecuggftrfgrthhtvghrnhepheelffeggedujeet iefhleetuddvieffhfffvdejvdffgeejkeduleduheduieefnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepphgvthgvrhdrvghishgvnhhtrhgr uhhtsegvnhhtvghrphhrihhsvggusgdrtghomh X-ME-Proxy: Feedback-ID: i131946ab:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 26 Jan 2023 03:39:06 -0500 (EST) Message-ID: Date: Thu, 26 Jan 2023 09:39:05 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: Generating code for query jumbling through gen_node_support.pl Content-Language: en-US To: Michael Paquier Cc: Postgres hackers , "Drouvot, Bertrand" References: <50b571dc-e0c0-22be-9803-4a3480d2e792@enterprisedb.com> From: Peter Eisentraut In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 25.01.23 01:08, Michael Paquier wrote: > On Tue, Jan 24, 2023 at 03:57:56PM +0900, Michael Paquier wrote: >> Makes sense. That would be my intention if 0004 is the most >> acceptable and splitting things makes things a bit easier to review. > > There was a silly mistake in 0004 where the jumbling code relied on > compute_query_id rather than utility_query_id, so fixed and rebased as > of v7 attached. Overall, this looks good to me. There are a couple of repetitive comments, like "typmod and collation information are irrelevant for the query jumbling". This applies to all nodes, so we don't need to repeat it for a number of nodes (and then not mention it for other nodes). Maybe there should be a central place somewhere that describes "these kinds of fields should normally be ignored".