Re: merging some features from plpgsql2 project

2017-01-02 18:36 GMT+01:00 Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)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)
>