Re: Add custom EXPLAIN options support to auto_explain

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
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