On Tue, Mar 4, 2025 at 8:56 AM Andrei Lepikhov <lepi...@gmail.com> wrote: > Passing through the patches, I would say that changing the order of 0001 > and 0002 would make them more independent.
Hmm, I thought this order made sense, but I could reorder them if there's some compelling reason to do so. If there's no particularly compelling reason, it would be less work to commit them in this order. > Also, I'm ok with the floating order of extension messages in the > explain output. We get used to living with dependencies on extension > load order (pg_stat_statements quite annoyingly impacts queryid, for > example), and this issue should be solved generally, in my opinion. I've often thought that the solution to this class of problems could be to have extensions not manipulate a hook variable directly, but instead call a function to which they pass their callback function and an integer priority. Then we could call hook functions in priority order. One difficulty is that this requires extension authors to agree on what the priority order should be. In some cases that might not be too hard, but it isn't apparent how it would work here. IMHO, it's reasonable for the author of an EXPLAIN extension to say "well, I see Robert already created an extension with an option called DEBUG, so I will name my option TROUBLESHOOT," or something of that sort. But if Robert gave the DEBUG hook priority 50, should I also give my hook priority 50, or should I make it 40 or 25 or 1 or 100 or what? Even if I know about all of the other extensions it's not really clear what I should do. Actually, in this case, it feels like it would be better if the user could control the ordering somehow, but I feel like that might be over-engineering. > I support the way where extensions are allowed to print info but not > restructure or remove something. > Wait for the commit! Cool, thanks. -- Robert Haas EDB: http://www.enterprisedb.com
