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@alvh.no-ip.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.