Re: [HACKERS] merging some features from plpgsql2 project

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)