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)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
