2017-01-03 18:41 GMT+01:00 Jim Nasby <jim.na...@bluetreble.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



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

Reply via email to