Horton

Re: making EXPLAIN extensible

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Peter Eisentraut <peter@eisentraut.org>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Jeff Davis <pgsql@j-davis.com>, Thom Brown <thom@linux.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-03-07T15:12:08Z
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 Fri, Mar 7, 2025 at 9:38 AM Peter Eisentraut <peter@eisentraut.org> wrote:
> Just to clarify this:  Nobody has gone through and used IWYU to clean up
> indirect includes, as you appear to imagine here.  My recent IWYU work
> was, besides putting some infrastructure in place, to clean up includes
> that are completely unneeded.  Indirect includes cleanup is a different
> project that is not currently happening, AFAIK.

OK, thanks. I wonder whether that's a good use of effort or just not
worth worrying about.

> Also, benign typedef redefinitions are a C11 feature.  In practice, all
> compilers currently in play support it, and the only problem you'll get
> is from the buildfarm members that are explicitly set up to warn about
> accidental C11 use.  We could probably have a discussion about that, but
> for this patch set, it's probably better to just deal with the status quo.

Agreed. +1 for having a discussion at some point, though, because the
effect of the current rules seems to be that you have to write "struct
BananaSplit *" in a bunch of places instead of just 'BananaSplit *" to
avoid redefining the typedef. That's worth doing it if it solves a
real problem, but if compilers where it is a real problem are extinct
in the wild, then I think I would prefer not to have to add the
"struct" keyword in a bunch of places just for compliance with
historical compiler behavior.

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