On Mon, Apr 6, 2026 at 12:27 PM Matheus Alcantara <[email protected]> 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]) > > That said, I think we should proceed with 0003 as-is and revisit this > when real-world usage reveals such problems in practice.
Agreed, I think we can lean on providers to do their part to make sure this works. FWIW, the main database-as-a-service provider I'm aware of that has a drop down for shared_preload_libraries today is Azure, and they do use alphabetic ordering in the UI. However I just checked, and the actual shared_preload_libraries value is not alphabetic (e.g. they put pg_cron first), so they just need to get the memo to handle this correctly. FWIW, AWS allows specifying the list in the same way postgresql.conf allows, and GCP has their own "cloudsql.enable_" flags mechanism, which presumably can also be taught to do the right thing. Thanks, Lukas -- Lukas Fittl
