On 1/2/17 12:06 PM, Pavel Stehule wrote:
> 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.
Yes, but the two cases you mentioned above are the "strange" cases, and
you should have to do something extra to allow those, not the other way
around.
> 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)
I see two problems with those settings:
1) Neither is enabled by default, so 90% of users have no idea they
exist. Obviously that's an easy enough fix, but...
2) There's no way to incrementally change those values for a single
function. If you've set extra_errors = 'all' globally, a single function
can't say "turn off the too many rows setting for this function".
BTW, while I can see value in being able to change these settings for an
entire function, I think the recommended use should be to only change
them for a specific statement.
--
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)