2017-01-08 3:27 GMT+01:00 Jim Nasby <jim.na...@bluetreble.com>: > On 1/5/17 11:36 AM, Merlin Moncure wrote: > >> The C language really should be considered the gold standard here. >> Changes did have to be made, like getting rid of the notoriously >> broken and insecure gets(), but they were made very, very slowly and >> unobtrusively. >> > > For those not familiar... how did they accomplish that? > > I'm certainly fine with changes being made very slowly. We carried the > missing_From GUC around for like a decade before ditching it. We have other > GUCs that have defaulted to not allowing silly behavior for a long time as > well. We might well need to leave the default for compatibility GUCs set to > current behavior for several more releases, to allow people to start > specifying which behavior they want. > > I agree with Robert that there needs to be consensus that a change needs > to be made, but frankly I think 50% of this thread was people disagreeing > with *ANY* change that would be incompatible. IMHO that's a ridiculous > position that does not match expectations outside of plpgsql. That kind of > expectation means we have absolutely no way of fixing past mistakes.
> Certainly, there also needs to be agreement on what the new behavior > should be, but again, what I observed was an adamant insistence that > absolutely no break would be permitted. > As for using GUCs for these changes and that impact on extensions, I don't > see why that won't work for what we're discussing here. In a worst-case > scenario, extension authors would need to specify what behavior they wanted > in their extensions instead of blindly accepting the default, by making > sure those options were set for each function they defined. While it would > certainly be nice to avoid that extra work, all the necessary > infrastructure to handle that is already in place. And if we wanted to > avoid that hassle, we could allow custom GUC settings on extensions, like > we currently do for roles and databases. The discussion related to plpgsql2, future development of plpgsql has more levels, topics 1. incompatible changes - INTO, INTO STRICT, FOUND - there is a agreement so current behave is not ideal for all cases, but there is not a agreement so it broken and should be "fixed" - GUC doesn't helps here. 2. new features - the question was "how much we would to move PL/pgSQL from verbose Ada language to different place - convention against configuration principle", and what (if) conventions should be default. GUC can partially helps. I still hope so there is some space for finding a partial agreement - and we can do some evolution steps forward. I would not to use GUC like "We cannot to find a agreement, so we use GUC and somebody will use this feature, some one not" - it is not way how to do things better long time. Jim, Marko, Joel - is there a place, features where we can find a partial agreement? If it is, then we can move our view there. 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) >
