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 1qJ77J-0005Il-UP for pgsql-hackers@arkaria.postgresql.org; Tue, 11 Jul 2023 06:44:58 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1qJ77I-0000Lt-Hp for pgsql-hackers@arkaria.postgresql.org; Tue, 11 Jul 2023 06:44:56 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qJ77I-0000Lj-4Y for pgsql-hackers@lists.postgresql.org; Tue, 11 Jul 2023 06:44:56 +0000 Received: from mail.postgrespro.ru ([93.174.131.139]) by makus.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1qJ77C-003DO8-UZ for pgsql-hackers@lists.postgresql.org; Tue, 11 Jul 2023 06:44:54 +0000 Received: from [192.168.28.143] (unknown [192.168.28.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: a.lepikhov@postgrespro.ru) by mail.postgrespro.ru (Postfix/587) with ESMTPSA id B63F3E20FBE; Tue, 11 Jul 2023 09:44:45 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mx2023; t=1689057888; bh=2U7OWYoGjkO3RuuuqYhyTp3A2FkaXBP6/7/oVoBCrxI=; h=Message-ID:Date:User-Agent:Subject:To:Cc:References:From: In-Reply-To:From; b=loSs+Ga1Vwt/7+8/Oq+fZwc12WJeyZ+34GbzxK63wP2BquLr38OXw9BXLPOxzxqks VR5dO57v5vj5oXzEtQXSr7gsNHHfZgMHN4kMsg6Lh4oUxaJDD3piBJdnKAvjioU8HN YfWUhaFh8UpSOBxJSEgXgZN06wt1PnthdkbsmtQy8GM4ieeUd21+CUVw3YhSRWXYL1 rk813TvKo2tXg870HgxSCwDhLoJ1srmJhscxoZG1JOWMk3c3XG5NjH/1sL6v0MtH7i 5pfMcU/hmE7rTJzvI7ZgMg6WgCyQUKtcgp+RdF30BpQCWP/Ow/XgJ4C+FW5aHUMJR1 SkszYwsyUKHRA== Message-ID: <1b92140d-ff31-21cb-3c06-e155471b87ac@postgrespro.ru> Date: Tue, 11 Jul 2023 13:44:39 +0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: Generating code for query jumbling through gen_node_support.pl Content-Language: en-US To: Michael Paquier Cc: Peter Eisentraut , Postgres hackers , "Drouvot, Bertrand" , "Jonathan S. Katz" References: <9695f035-0f2b-92b9-deed-0b7e5bb7e4e0@enterprisedb.com> <268fd337-8bb7-92e6-0da2-416c022c11f3@enterprisedb.com> <5bcbf926-3d5a-e953-79a6-b6ab0f8b23a0@postgrespro.ru> From: Andrey Lepikhov Organization: Postgres Professional 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 11/7/2023 12:35, Michael Paquier wrote: > On Tue, Jul 11, 2023 at 12:29:29PM +0700, Andrey Lepikhov wrote: >> I vote for only one method based on a query tree structure. > > Noted > >> BTW, did you think about different algorithms of queryId generation? > > Not really, except if you are referring to the possibility of being > able to handle differently different portions of the nodes depending > on a context given by the callers willing to do a query jumbling > computation. (For example, choose to *not* silence the Const nodes, > etc.) Yes, I have two requests on different queryId algorithms: 1. With suppressed Const nodes. 2. With replacement of Oids with full names - to give a chance to see the same queryId at different instances for the same query. It is quite trivial to implement, but not easy in support. > >> Auto-generated queryId code can open a way for extensions to have >> easy-supporting custom queryIds. > > Extensions can control that at some extent, already. > -- > Michael -- regards, Andrey Lepikhov Postgres Professional