On 1/2/17 1:51 PM, Pavel Stehule wrote:
> 1) Neither is enabled by default, so 90% of users have no idea they
> exist. Obviously that's an easy enough fix, but...
>
> We can strongly talk about it - there can be a chapter in plpgsql doc.
> Now, the patterns and antipatterns are not officially documented.
Or just fix the issue, provide the backwards compatability GUCs and move on.
> 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".
>
>
> We can enhance the GUC syntax like "all -too_many_rows,-xxx"
Why create all that framework when we could just have multiple
plpgsql.blah GUCs? plpgsql.multirow_assign_level=FATAL solves that
problem. We just need a plpgsql GUC for each backwards compatibility break.
> 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.
>
>
> What you can do in plain assign statement
>
> target := expression ?
The point I was trying to make there is if you do have some cases where
you need to silently ignore extra rows (for example) it's probably only
one statement and not an entire function. That said, if we just make
these options GUCs then you can just do SET and RESET.
> My border is any compatibility break - and I would not to across it.
> First issue is probably harder
If we never broke compatibility we'd still be allowing SELECT without
FROM, NULL = NULL being TRUE, and a whole bunch of other problems. We'd
also be stuck on protocol v1 (and of course not talking about what we
want in v4).
We've successfully made incompatible changes that were *far worse* than
this (ie: renaming pg_stat_activity.procpid). Obviously we shouldn't be
breaking things willy-nilly, but these are long-standing warts (dare I
say BUGS?) that should be fixed. They're ugly enough that someone took
the time to break plpgsql out of the core code and fork it.
--
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)