2017-01-02 18:36 GMT+01:00 Jim Nasby <jim.na...@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) >
