Re: [HACKERS] merging some features from plpgsql2 project

On 1/3/17 11:19 AM, Pavel Stehule wrote:
>             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.
>
> We have this framework already, so why don't use it.

We *don't* have a framework that works for this, because you can't 
incrementally modify extra_errors. Maybe extra_errors is an OK API for 
static checking, but it's definitely a BAD API for something you'd need 
to control at a function (or even statement) level.

>     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).
>
>
> This was in dark age - how much users of plpgsql was in 2000? Hard to
> speak about Postgres as mature software in this era.

I don't know about you' but I've considered Postgres to be mature since 
at least 8.0, if not earlier. Actually, in many ways it was far more 
mature than other databases I was using in 2000 (let alone 2007).

>     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.
>
> We are not talk about features that can be simply marked as bugs, so
> there is not too much what we should to fix it. We should to help to
> users to identify some possible risk places.

You keep claiming that these aren't serious bugs, yet someone felt so 
strongly that they ARE serious bugs that they forked the entire PL.

If you're not willing to even consider a compatibility break (with a 
means to get the old behavior back) then I don't think there's any point 
in continuing this thread, because some of these issues can NOT be 
reasonably solved by a checker.
-- 
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)