Re: Support a wildcard in backtrace_functions

Поиск
Список
Период
Сортировка
От Jelte Fennema-Nio
Тема Re: Support a wildcard in backtrace_functions
Дата
Msg-id CAGECzQQUdunbdK+e_60SAwmfgvvuS9g4x1QthuOBcf_gn5S29g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Support a wildcard in backtrace_functions  (Peter Eisentraut <peter@eisentraut.org>)
Ответы Re: Support a wildcard in backtrace_functions  (Peter Eisentraut <peter@eisentraut.org>)
Список pgsql-hackers
On Thu, 18 Apr 2024 at 10:50, Peter Eisentraut <peter@eisentraut.org> wrote:
> Why exactly is this an open item?  Is there anything wrong with the
> existing feature?

The name of the GUC backtrace_on_internal_error is so specific that
it's impossible to extend our backtrace behaviour in future releases
without adding yet another backtrace GUC. You started the discussion
on renaming it upthread:

On Fri, 8 Mar 2024 at 15:51, Peter Eisentraut <peter@eisentraut.org> wrote:
> 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}?



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: BitmapHeapScan streaming read user and prelim refactoring
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: WIP Incremental JSON Parser