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)
