MIME-Version: 1.0
References: <DHCYFNC0WIF4.3T1M8AUK0DG7T@gmail.com>
 <CA+Tgmob-0W8306mvrJX5Urtqt1AAasu8pi4yLrZ1XfwZU-Uj1w@mail.gmail.com>
 <CA+TgmoYUdeCdGfk8H6Ni2obXVixLvYaDkRGtxKLEmaCVNffsVA@mail.gmail.com>
 <DHHB7U2PSFYG.1A0WVPTX5LNOD@gmail.com>
 <CA+TgmoacOujCREMtQwURTSokB+ks-eLgaQ5vBMdWG959XzFcrA@mail.gmail.com>
 <CAP53PkwsnhmoLXJaUMKWc76S21GzYOX06qKyZdVZhGGW0rCWKw@mail.gmail.com>
 <DHMBIO0G7WL4.1EMZ7AG9ZS148@gmail.com>
In-Reply-To: <DHMBIO0G7WL4.1EMZ7AG9ZS148@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
Date: Mon, 6 Apr 2026 15:35:00 -0400
Message-ID: 
 <CA+Tgmob6FPjpWTnXR++7UaCKrfO8S761Uk+sqkMpQrVyGNsXnA@mail.gmail.com>
Subject: Re: Add custom EXPLAIN options support to auto_explain
To: Matheus Alcantara <matheusssilv97@gmail.com>
Cc: Lukas Fittl <lukas@fittl.com>, pgsql-hackers@lists.postgresql.org,
	Tom Lane <tgl@sss.pgh.pa.us>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CA%2BTgmob6FPjpWTnXR%2B%2B7UaCKrfO8S761Uk%2BsqkMpQrVyGNsXnA%40mail.gmail.com>
Precedence: bulk

On Mon, Apr 6, 2026 at 3:27=E2=80=AFPM Matheus Alcantara
<matheusssilv97@gmail.com> wrote:
> I did another review of 0003 (0001 and 0002 are now committed), focusing
> on auto_explain_split_options(). I didn't find any issues. The code
> coverage looks good - auto_explain_split_options() has nearly 100%
> coverage and the new code paths are well exercised by the tests.

Thanks. I just committed it.

> My concern is about that some cloud providers expose
> shared_preload_libraries as a dropdown without user control over
> ordering. I can be totally wrong, but it seems to me that in this case,
> the provider would need to handle dependencies appropriately or have a
> way to let the user define the ordering. Or, a possible improvement
> would be a post-configuration validation hook that runs after all
> shared_preload_libraries are loaded, allowing deferred validation of
> cross-extension dependencies like these EXPLAIN options (I'm wondering
> that we can have more extension dependencies in the future, e.g
> plan_advice and pg_stat_statements [1])

I think this probably collides rather badly with the GUC machinery:
GUC validation can be deferred "a little bit," but the GUC system
itself decides on the timing of validation, and there's no way for the
GUC's check hook to say "please come back later". I suspect that
property of the GUC system is too deeply embedded for us to think
about changing it.

> That said, I think we should proceed with 0003 as-is and revisit this
> when real-world usage reveals such problems in practice.

Yeah, it's frustrating to not be able to do something better than this
for this release, but the great news is that there will very likely be
another release next year. :-)

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