Horton

Re: making EXPLAIN extensible

Andrei Lepikhov <lepihov@gmail.com>

View thread
From: Andrei Lepikhov <lepihov@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Sami Imseih <samimseih@gmail.com>, Jeff Davis <pgsql@j-davis.com>, Thom Brown <thom@linux.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2025-05-22T14:28:58Z
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. pg_overexplain: Use PG_MODULE_MAGIC_EXT.

  2. pg_overexplain: Call previous hooks as appropriate.

  3. pg_overexplain: Additional EXPLAIN options for debugging.

  4. Add an additional hook for EXPLAIN option validation.

  5. Add some new hooks so extensions can add details to EXPLAIN.

  6. Make it possible for loadable modules to add EXPLAIN options.

On 22/5/2025 16:17, Robert Haas wrote:
> On Sat, May 3, 2025 at 2:44 PM Andrei Lepikhov <lepihov@gmail.com> wrote:
>> I have one additional proposal.
>>
>> I currently use this interface and have noticed that the parameter
>> `option_name` in the RegisterExtensionExplainOption routine is
>> case-sensitive. Since SQL treats our extended options as
>> case-insensitive, it would be beneficial to either add a comment
>> clarifying this behavior or forcedly convert incoming text constant to
>> lowercase.
> 
> I don't think this is really true. It's just standard identifier
> handling. You can have options with upper-case names if you quote
> them.
Sorry for my language. I meant that when you call function 
RegisterExtensionExplainOption(), it make sense if you write parameter 
`option_name` as "debug" or "deBug". On the user side 
case-insensitiveness works correctly, of course. Not sure about side 
effects if one extension will call this routine with "Debug" parameter 
and another one - "debuG".

-- 
regards, Andrei Lepikhov