Re: making EXPLAIN extensible
От | Robert Haas |
---|---|
Тема | Re: making EXPLAIN extensible |
Дата | |
Msg-id | CA+TgmoZ8sTodL-orXQm51_npNxuDAS86BS5kC8t0LULneShRbg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: making EXPLAIN extensible (Matheus Alcantara <matheusssilv97@gmail.com>) |
Список | pgsql-hackers |
First, thanks to all who have said they like this idea. I wasn't expecting this much enthusiasm, to be honest. Woohoo! On Mon, Mar 3, 2025 at 8:27 AM Matheus Alcantara <matheusssilv97@gmail.com> wrote: > It would make sense (or possible) to have some kind of validation that returns > an error when using an option that is ambiguous? If a option is unique for all > options registered via extensions than the extension name prefix is not needed, > otherwise an error is returned forcing the user to specify the extension name. I'm not saying that this couldn't be done -- it definitely could -- but to me it seems somewhat pointless. I mean, you'd just get the error when you try to load the second of the two extensions, and then what are you supposed to do about it at that point? Really, it's incumbent on EXPLAIN-extension developers to avoid picking names that conflict with other EXPLAIN extensions that the same users might want to use. If they don't do that, everything sucks. By jiggering things around you can cause the result to be either (a) some options are ignored (current behavior) or (b) errors occur during extension loading (your proposal) or (c) errors occur at runtime or even (d) suddenly the conflicting options need to be spelled in a very verbose way with a module name prefix instead of using them normally. But I think no matter which of those things happen, life is pretty bad for the user. The only real solution, AFAICS, is for the extension developers to be thoughtful about the option names that they pick. I'm not saying that's definitely going to happen, and I can be convinced to add something to the patch to cater to it. But only if we all agree on exactly what to add and exactly why that's going to be better than doing nothing. My current view - as explained above - is that anything we add is just going to be increasing the amount of code without really making the user experience any better. If that's correct, it's better to just keep it simple, as I have done. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: