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