On Thu, Apr 18, 2024 at 12:21:56PM +0200, Jelte Fennema-Nio wrote:
> On Thu, 18 Apr 2024 at 09:02, Michael Paquier <michael@paquier.xyz> wrote:
>> On Fri, Apr 12, 2024 at 09:36:36AM +0900, Michael Paquier wrote:
>> log_backtrace speaks a bit more to me as a name for this stuff because
>> it logs a backtrace. Now, there is consistency on HEAD as well
>> because these GUCs are all prefixed with "backtrace_". Would
>> something like a backtrace_mode where we have an enum rather than a
>> boolean be better?
>
> I guess it depends what we want consistency with. If we want naming
> consistency with all other LOGGING_WHAT GUCs or if we want naming
> consistency with the current backtrace_functions GUC. I personally
> like log_backtrace slightly better, but I don't have a super strong
> opinion on this either. Another option could be plain "backtrace".
"backtrace" is too generic IMO. I'd append a "mode" as an effect of
backtrace_functions, which is also a developer option, and has been
around for a couple of releases now.
>> One thing would be to redesign the existing GUC as
>> having two values on HEAD as of:
>> - "none", to log nothing.
>> - "internal", to log backtraces for internal errors.
>
> If we go for backtrace_mode or backtrace, then I think I'd prefer
> "disabled"/"off" and "internal_error" for these values.
"internal_error" as a value sounds fine to me, that speaks more than
just "internal". "off" rather that "none" or "disabled", less so,
because it requires more enum entries to map with the boolean values
that could be expected from it. "disabled" would be mostly a first in
the GUCs, icu_validation_level being the first one using it, so I'd
rather choose "none" over "disabled". No strong preference on this
one, TBH, but as we're bike-shedding that..
--
Michael