Re: PL/pgSQL, RAISE and error context

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: PL/pgSQL, RAISE and error context
Дата
Msg-id CAFj8pRD_ohp8YaHkkNGOEeFWZkyW4CYk9rc=96azQrNunJ_3rg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: PL/pgSQL, RAISE and error context  (Joel Jacobson <joel@trustly.com>)
Ответы Re: PL/pgSQL, RAISE and error context  (Joel Jacobson <joel@trustly.com>)
Список pgsql-hackers


2015-04-24 16:02 GMT+02:00 Joel Jacobson <joel@trustly.com>:
On Fri, Apr 24, 2015 at 1:16 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> This would allow doing something crazy as:
>>
>> suppress_context_messages = warning,error
>> display_context_messages = notice
>
> This is a very flexible proposal, but it's a tremendous amount of
> machinery for what's really a very minor issue.  If we added two GUCs
> for every comparably important issue, we'd have about 40,000 of them.

I agree. The one-dimensional GUC syntax is not well suited for
multi-dimensional config settings. And that's a good thing mostly I
think. It would be a nightmare if the config file values could in JSON
format, it's good they are simple.

But I'm thinking maybe we could improve the config file syntax for the
general case when you have multiple things you want to control, in
this case the message levels, and for each such thing, you want to
turn something on/off, in this case the CONTEXT. Maybe we could simply
use plus "+" and minus "-" to mean "on" and "off"?

Example:

context_messages = -warning, -error, +notice

I prefer your first proposal - and there is a precedent for plpgsql -  plpgsql_extra_checks

It is clean for anybody. +-identifiers looks like horrible httpd config. :)

Regards

Pavel

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

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: a fast bloat measurement tool (was Re: Measuring relation free space)
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: tablespaces inside $PGDATA considered harmful