Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Mon, 06 Apr 2026 16:58:01 -0300
Message-Id: <DHMC5XQVV9LK.1PG9EAWKZ13AC@gmail.com>
Cc: "Lukas Fittl" <lukas@fittl.com>, <pgsql-hackers@lists.postgresql.org>,
 "Tom Lane" <tgl@sss.pgh.pa.us>
Subject: Re: Add custom EXPLAIN options support to auto_explain
From: "Matheus Alcantara" <matheusssilv97@gmail.com>
To: "Robert Haas" <robertmhaas@gmail.com>
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>
 <CA+Tgmob6FPjpWTnXR++7UaCKrfO8S761Uk+sqkMpQrVyGNsXnA@mail.gmail.com>
In-Reply-To: 
 <CA+Tgmob6FPjpWTnXR++7UaCKrfO8S761Uk+sqkMpQrVyGNsXnA@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/DHMC5XQVV9LK.1PG9EAWKZ13AC%40gmail.com>
Precedence: bulk

On Mon Apr 6, 2026 at 4:35 PM -03, Robert Haas wrote:
>> 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.

I was saying something like post_guc_init_hook() that is called after
all GUC variables are initialized. For example, the
check_log_extension_options() will only check if the syntax is correct
and later the post_guc_init_hook() (via auto_explain) will be responsible=
=20
to check that the options are valid or not. I didn't check the code in
detail to see if this make any sense or not, but if it make I don't
think that will be easy either because we call InitializeGUCOptions()
very early than process_shared_preload_libraries(). Anyway this was
something that I thought during the discussion.

--
Matheus Alcantara
EDB: https://www.enterprisedb.com