Re: merging some features from plpgsql2 project

2017-01-03 18:41 GMT+01:00 Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>:

> 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.

I have different opinion then you - sure - it should not to change behave,
it should to help with identification. And it is enough for this purpose.

>
>
> 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.
>

Sorry, but it it is subjective - and there can be different opinions - some
body would to prefer more rigidity, some other less rigidity.

>
> 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.

yes, I don't would to consider about a compatibility break. I accept so you
have different opinion.

I'll send this patch + doc to next commitfest - and depends on commiters if
the patch will be rejected or not. I know so it should not be fully fixed,
but it is step forward from my perspective.

Thank you for discussion

Regards

Pavel

>
> --
> 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)
>