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)
