2016-12-28 20:25 GMT+01:00 Jim Nasby <jim.na...@bluetreble.com>: > On 12/28/16 12:51 PM, Pavel Stehule wrote: > >> Now, the incompatibility can be hard issue - it is big question if we >> lock some users on old versions because some users can save to lines of >> code. Introduction of ROW_COUNT is lowly incompatibility - it can be >> simply detected - but for example change of behave of FOUND variable is >> terrible, because the code will be quietly calculate differently. >> sometimes we can break code - probably people will not be happy, but >> sometimes we can change the results - it can be big fail. So on one side >> is big costs. On second side is few lines less code. >> > > That's my whole point of why this needs to be settable at a global level: > so that people with a lot of legacy code can set the OLD behavior at a > global level, and deal with the old code over time. > > If there's no global setting then there are only two choices: we default > to new behavior and force everyone to add a bunch of stuff to *every* > function they have (loads of complaints), or we default to old behavior and > no one bothers to even adopt the new usage because they have to add extra > stuff to every function. Either way is a failure. This is why I think there > MUST be some way to control this at a higher level than per function. > > we can have both - plpgsql.variable_conflict can be precedent.
> Certainly GUCs aren't the only option, we could invent something else. One > feature I could see being useful is being able to set a default on a schema > level, which isn't currently possible with a GUC. But I can certainly see > database and global settings being useful, and perhaps per-user as well. > GUCs already have those. yes, without GUC you cannot set the behave of plpgsql globally. 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) >
