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