Re: [HACKERS] merging some features from plpgsql2 project

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: [HACKERS] merging some features from plpgsql2 project
Дата
Msg-id CAFj8pRB14KrM8VQMjLduuPYDN5sk5S3_Wbcw4jvUzOiDc-jrxg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] merging some features from plpgsql2 project  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Ответы Re: [HACKERS] merging some features from plpgsql2 project  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Список pgsql-hackers


2017-01-02 18:36 GMT+01:00 Jim Nasby <Jim.Nasby@bluetreble.com>:
On 1/1/17 12:17 PM, Pavel Stehule wrote:
I wrote some initial patch

Do you think so has sense to continue in this topic?

Perhaps I'm not understanding what plpgsql_extra_errors does, but I don't think either of these should depend on that being true. IMO these two checks should be default to throwing an exception.

There are use cases where these patters should be used and has sense like

SELECT (polymorphiccomposite).* INTO c1, c2; -- take first two columns

SELECT xx FROM tab ORDER BY yy INTO target -- more rows not a issue

I understand plpgsql_extra_errors as feature that can be enabled on developer, test, or preprod environments and can help to identify some strange places. 
 

I think instead of tying these to extra_*, each GUC should accept a LOG level.

Why? Why the none, warning, error are not enough? Why are you think so separate GUC can be better than plpgsql_extra_* ? 

The fast setting plpgsql.extra_errors = 'all' can switch to some "safe" configuration. 
The fast setting plpgsql.extra_warnings = 'all' can helps with identification, but doesn't break production (or doesn't breaks other tests)

Regards

Pavel
 

--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)

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

Предыдущее
От: David Steele
Дата:
Сообщение: Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] Clarifying "server starting" messaging in pg_ctl startwithout --wait