Re: [HACKERS] merging some features from plpgsql2 project

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.

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.

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