Horton

Re: Proposal - Allow extensions to set a Plan Identifier

Michael Paquier <michael@paquier.xyz>

View thread
From: Michael Paquier <michael@paquier.xyz>
To: Sami Imseih <samimseih@gmail.com>
Cc: Andrei Lepikhov <lepihov@gmail.com>, Bertrand Drouvot <bertranddrouvot.pg@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, Lukas Fittl <lukas@fittl.com>
Date: 2025-03-24T04:43:03Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Allow plugins to set a 64-bit plan identifier in PlannedStmt

On Sat, Mar 22, 2025 at 10:22:37PM -0500, Sami Imseih wrote:
> I think plan_node_id is probably the least controversial because that value
> comes straight from core, and different extensions cannot have their own
> interpretation of what that value could be.

Depends.  An extension can plug in what they want.  The point is that
the key used to identify a single plan is up to what extensions think
is relevant in a plan.  That's heavily subject to interpretation.
What's not really subject to interpretation is that an extension
cannot know it should set and/or use as key identifier without
something that some portion pf the code structures knows about, or
these extensions have an inter-dependency.  Anyway, there are also the 
arguments about the set timing, reset timing, the extended protocol
argument, etc.  So I've applied the patch for now, to start with
something.

> FWIW, Lukas did start a Wiki [0] to open the discussion for what parts
> of the plan should be used to compute a plan_id, and maybe we can
> in the future compite a plan_id in core by default.

Let's see where this leads..  I suspect that this is going to take
some time, assuming that we're ever able to settle on a clear
definition.  Perhaps we will, or perhaps we will not.
--
Michael