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 1rpvom-009YfA-Ov for pgsql-hackers@arkaria.postgresql.org; Thu, 28 Mar 2024 19:53:45 +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 1rpvol-002uvt-Ge for pgsql-hackers@arkaria.postgresql.org; Thu, 28 Mar 2024 19:53:43 +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 1rpvol-002uu6-6m for pgsql-hackers@lists.postgresql.org; Thu, 28 Mar 2024 19:53:43 +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 1rpvoh-006vzf-IL for pgsql-hackers@lists.postgresql.org; Thu, 28 Mar 2024 19:53:41 +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 42SJrdEY3704836; Thu, 28 Mar 2024 15:53:39 -0400 From: Tom Lane To: David Rowley cc: Richard Guo , Alexander Lakhin , PostgreSQL Developers Subject: Re: Properly pathify the union planner In-reply-to: <3703023.1711654574@sss.pgh.pa.us> References: <242fc7c6-a8aa-2daf-ac4c-0a231e2619c1@gmail.com> <3485967.1711594595@sss.pgh.pa.us> <3703023.1711654574@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Thu, 28 Mar 2024 15:36:14 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3704834.1711655619.1@sss.pgh.pa.us> Date: Thu, 28 Mar 2024 15:53:39 -0400 Message-ID: <3704835.1711655619@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk I wrote: > David Rowley writes: >> Maybe something with "Parameters" in the name? > SubqueryParameters might be OK. Or SubqueryPlannerExtra? > Since this is a bespoke struct that will probably only ever > be used with subquery_planner, naming it after that function > seems like a good idea. On third thought, I'm not at all convinced that we even want to invent this struct as compared to just adding another parameter to subquery_planner. The problem with a struct is what happens the next time we need to add a parameter? If we add yet another function parameter, we can count on the compiler to complain about call sites that didn't get the memo. Adding a field within an existing struct provokes no such warning, leading to situations with uninitialized fields that might accidentally work during testing, but fail the minute they get to the field. If you do want to go this direction, a minimum safety requirement would be to have an ironclad rule that callers memset the whole struct to zero before filling it, so that any not-set fields will at least have predictable values. But I don't see the point really. regards, tom lane