From: "Andrey V. Lepikhov" <a.lepikhov@postgrespro.ru>
Subject: Clarify planner_hook calling convention
To: PostgreSQL-Dev <pgsql-hackers@postgresql.org>
Organization: Postgres Professional
Message-ID: <5eb6f0f3-4618-f835-ddc8-41c97b208551@postgrespro.ru>
Date: Mon, 3 Jan 2022 12:33:13 +0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.14.0
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="------------9C5A18A28F9D55FE11F91AE9"
Content-Language: en-US
Archived-At: <https://www.postgresql.org/message-id/5eb6f0f3-4618-f835-ddc8-41c97b208551%40postgrespro.ru>
Precedence: bulk

This is a multi-part message in MIME format.
--------------9C5A18A28F9D55FE11F91AE9
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

planner hook is frequently used in monitoring and advising extensions. 
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. 
Moreover, if an extension make some expensive planning activity, 
monitoring tools, like pg_stat_statements, can produce different 
results, depending on a hook calling order.
I thought about additional hooks, explicit hook priorities and so on. 
But, maybe more simple solution is to describe requirements to such kind 
of extensions in the code and documentation (See patch in attachment)?
It would allow an extension developer legally check and log a situation, 
when the extension doesn't last in the call chain.


[1] 
https://www.postgresql.org/message-id/flat/27516.1180053940%40sss.pgh.pa.us

-- 
regards,
Andrey Lepikhov
Postgres Professional

--------------9C5A18A28F9D55FE11F91AE9
Content-Type: text/x-patch; charset=UTF-8;
 name="clarify_planner_hook_usage.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="clarify_planner_hook_usage.diff"

diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index afbb6c35e3..79a5602850 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -9401,6 +9401,7 @@ SET XML OPTION { DOCUMENT | CONTENT };
         double quotes if you need to include whitespace or commas in the name.
         This parameter can only be set at server start.  If a specified
         library is not found, the server will fail to start.
+        Libraries are loaded in the order in which they appear in the list.
        </para>
 
        <para>
diff --git a/src/backend/optimizer/plan/planner.c b/src/backend/optimizer/plan/planner.c
index bd01ec0526..7251b88ad1 100644
--- a/src/backend/optimizer/plan/planner.c
+++ b/src/backend/optimizer/plan/planner.c
@@ -261,8 +261,11 @@ static int	common_prefix_cmp(const void *a, const void *b);
  * after the standard planning process.  The plugin would normally call
  * standard_planner().
  *
- * Note to plugin authors: standard_planner() scribbles on its Query input,
- * so you'd better copy that data structure if you want to plan more than once.
+ * Notes to plugin authors:
+ * 1. standard_planner() scribbles on its Query input, so you'd better copy that
+ * data structure if you want to plan more than once.
+ * 2. If your extension implements some planning activity, write in the extension
+ * docs a requirement to set the extension at the begining of shared libraries list.
  *
  *****************************************************************************/
 PlannedStmt *

--------------9C5A18A28F9D55FE11F91AE9--