Re: Support a wildcard in backtrace_functions

On 08.03.24 12:25, Jelte Fennema-Nio wrote:
> On Fri, 8 Mar 2024 at 10:59, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
>>
>> On 2024-Mar-08, Bharath Rupireddy wrote:
>>
>>> This works only if '* 'is specified as the only one character in
>>> backtrace_functions = '*', right? If yes, what if someone sets
>>> backtrace_functions = 'foo, bar, *, baz'?
>>
>> It throws an error, as expected. This is a useless waste of resources:
>> checking for "foo" and "bar" is pointless, since the * is going to give
>> a positive match anyway. And the "baz" is a waste of memory which is
>> never going to be checked.
>
> Makes sense. Attached is a new patchset that implements it that way.
> I've not included Bharath his 0003 patch, since it's a much bigger
> change than the others, and thus might need some more discussion.

What is the relationship of these changes with the recently added
backtrace_on_internal_error? We had similar discussions there, I feel
like we are doing similar things here but slightly differently. Like,
shouldn't backtrace_functions_min_level also affect
backtrace_on_internal_error? Don't you really just want
backtrace_on_any_error? You are sneaking that in through the backdoor
via backtrace_functions. Can we somehow combine all these use cases
more elegantly? backtrace_on_error = {all|internal|none}?

Btw., your code/documentation sometimes writes "stack trace". Let's
stick to backtrace for consistency.