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)