Re: Improve GetConfigOptionValues function
От | Tom Lane |
---|---|
Тема | Re: Improve GetConfigOptionValues function |
Дата | |
Msg-id | 2240632.1674573203@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Improve GetConfigOptionValues function (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>) |
Ответы |
Re: Improve GetConfigOptionValues function
Re: Improve GetConfigOptionValues function |
Список | pgsql-hackers |
Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> writes: > On Mon, Jan 23, 2023 at 9:51 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Also, I intentionally dropped the GUC_NO_SHOW_ALL check in >> get_explain_guc_options, because it seems redundant given >> the preceding GUC_EXPLAIN check. It's unlikely we'd ever have >> a variable that's marked both GUC_EXPLAIN and GUC_NO_SHOW_ALL ... >> but if we did, shouldn't the former take precedence here anyway? > You're right, but there's nothing that prevents users writing GUCs > with GUC_EXPLAIN and GUC_NO_SHOW_ALL. "Users"? You do realize those flags are only settable by C code, right? Moreover, you haven't explained why it would be good that you can't get at the behavior that a GUC is both shown in EXPLAIN and not shown in SHOW ALL. If you want "not shown by either", that's already accessible by setting only the GUC_NO_SHOW_ALL flag. So I'd almost argue this is a bug fix, though I concede it's a bit hard to imagine why somebody would want that choice. Still, if we have two independent flags they should produce four behaviors, not just three. regards, tom lane
В списке pgsql-hackers по дате отправления: