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)