Horton

Re: making EXPLAIN extensible

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Andrei Lepikhov <lepihov@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-22T15:09:41Z
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 Thu, May 22, 2025 at 10:29 AM Andrei Lepikhov <lepihov@gmail.com> wrote:
> > 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".

I guess my point is that this works just like other cases where SQL
identifiers are accessible in C code: they're normally lower-case but
they don't have to be if the user quoted them. I don't think it's
worth adding a comment about that general behavior to this specific
bit of code.

-- 
Robert Haas
EDB: http://www.enterprisedb.com