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 1n4Pka-0002st-5X for pgsql-hackers@arkaria.postgresql.org; Mon, 03 Jan 2022 15:59:56 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1n4PkZ-0006Vb-2z for pgsql-hackers@arkaria.postgresql.org; Mon, 03 Jan 2022 15:59:55 +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 1n4PkY-0006VK-QU for pgsql-hackers@lists.postgresql.org; Mon, 03 Jan 2022 15:59:54 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n4PkW-0004j3-7G for pgsql-hackers@postgresql.org; Mon, 03 Jan 2022 15:59:53 +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 203FxkVI3560244; Mon, 3 Jan 2022 10:59:47 -0500 From: Tom Lane To: "Andrey V. Lepikhov" cc: PostgreSQL-Dev Subject: Re: Clarify planner_hook calling convention In-reply-to: <5eb6f0f3-4618-f835-ddc8-41c97b208551@postgrespro.ru> References: <5eb6f0f3-4618-f835-ddc8-41c97b208551@postgrespro.ru> Comments: In-reply-to "Andrey V. Lepikhov" message dated "Mon, 03 Jan 2022 12:33:13 +0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3560242.1641225586.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Mon, 03 Jan 2022 10:59:46 -0500 Message-ID: <3560243.1641225586@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk "Andrey V. Lepikhov" writes: > planner hook is frequently used in monitoring and advising extensions. = Yeah. > The call to this hook is implemented in the way, that the = > standard_planner routine must be called at least once in the hook's call= = > chain. > But, as I see in [1], it should allow us "... replace the planner = > altogether". > In such situation it haven't sense to call standard_planner at all. = That's possible in theory, but who's going to do it in practice? There is a monstrous amount of code you'd have to replace. Moreover, if you felt compelled to do it, it's likely because you are making fundamental changes elsewhere too, which means you are more likely going to end up with a fork not an extension. > But, maybe more simple solution is to describe requirements to such kind= = > of extensions in the code and documentation (See patch in attachment)? > + * 2. If your extension implements some planning activity, write in the= extension > + * docs a requirement to set the extension at the begining of shared li= braries list. This advice seems pretty unhelpful. If more than one extension is getting into the planner_hook, they can't all be first. (Also, largely the same issue applies to very many of our other hooks.) regards, tom lane