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 1tvfCY-006sWj-Bw for pgsql-hackers@arkaria.postgresql.org; Fri, 21 Mar 2025 16:26:30 +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 1tvfCW-00B4Os-LG for pgsql-hackers@arkaria.postgresql.org; Fri, 21 Mar 2025 16:26:28 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tvfCW-00B4Ok-BV for pgsql-hackers@lists.postgresql.org; Fri, 21 Mar 2025 16:26:28 +0000 Received: from mout-p-101.mailbox.org ([80.241.56.151]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1tvfCT-000Lok-2v for pgsql-hackers@lists.postgresql.org; Fri, 21 Mar 2025 16:26:27 +0000 Received: from smtp1.mailbox.org (smtp1.mailbox.org [10.196.197.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-101.mailbox.org (Postfix) with ESMTPS id 4ZK79p2JmZz9tCD; Fri, 21 Mar 2025 17:26:22 +0100 (CET) Date: Fri, 21 Mar 2025 17:26:20 +0100 From: Christoph Berg To: Michael Paquier Cc: PostgreSQL Hackers , ma lz Subject: Re: query_id: jumble names of temp tables for better pg_stat_statement UX Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Re: Michael Paquier > I have been thinking about this patch for a couple of days. What > makes me unhappy in this proposal is that RangeTblEntry is a large and > complicated Node, and we only want to force a custom computation for > the "relid" portion of the node, while being able to also take some > decisions for what the parent node has. Leaving the existing > per-field query_jumble_ignore with the custom function is prone to > errors, as well, because we need to maintain some level of consistency > between parsenodes.h and src/backend/nodes/. Ack, that was also bothering me, but I didn't think it was so easy to do it on a per-field level. Thanks! > The custom functions are named _jumble${node}_${field}, with the field > and the parent node given as arguments. I agree that giving the field > is kind of pointless if you have the parent node, but I think that > this is better so as this forces developers to think about how to use > the field value with the node. Makes sense. > Please see the attached. What do you think? Just one minor thing, I don't understand what you are trying to say in this comment: > +/* > + * Note that the argument types are enforced for the per-field custom > + * functions. > + */ > +#define JUMBLE_CUSTOM(nodetype, item) \ > + _jumble##nodetype##_##item(jstate, expr, expr->item) Thanks, Christoph