Re: making EXPLAIN extensible

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Sami Imseih <samimseih(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Andrei Lepikhov <lepihov(at)gmail(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, Thom Brown <thom(at)linux(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: making EXPLAIN extensible
Date: 2025-03-21 18:37:05
Message-ID: 1584338.1742582225@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Sami Imseih <samimseih(at)gmail(dot)com> writes:
> overall this LGTM, and I don't really have other comments.

I took a look through v8, and have just a couple of trivial nits:

+static void overexplain_debug_handler(ExplainState *, DefElem *,
+ ParseState *);
+static void overexplain_range_table_handler(ExplainState *, DefElem *,
+ ParseState *);

I cordially hate this parameter-name-less style of function
declaration, and consider it Stroustrup's single worst idea in C++.
It rests on the assumption that parameter names convey zero
information, which is wrongheaded for any function more complex than,
say, addition. Also, even if you like this style, clang-tidy probably
won't (cf for example 035ce1feb).

pgoverexplain.sgml seems to have been formatted to fit in about an
85-column window. Please don't do that --- you might as well have
made it 99 columns wide or any other random number, it still looks
like heck in 80 columns.

Other than that, there's room to debate exactly what to show.
But as long as we're agreed that we won't hold this module to
high cross-version compatibility standards, that doesn't seem
like a problem. I'm okay with this as a starting point.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2025-03-21 18:54:31 Re: Update Unicode data to Unicode 16.0.0
Previous Message Jeff Davis 2025-03-21 18:26:53 Re: Update Unicode data to Unicode 16.0.0