2016-12-28 19:23 GMT+01:00 Jim Nasby <jim.na...@bluetreble.com>: > On 12/28/16 12:15 PM, Pavel Stehule wrote: > >> GUC are fragile - the source code and settings can be separated. >> > > *Can* be, but they don't *have* to be. That's a huge feature, not a bug. > > Our #option is more robust, because source code holds all flags required >> for execution. So I would to see a mechanism, that will be strongly >> joined with code. >> > > That means you must ALWAYS specify, which is an enormous pain. It > basically guarantees that users will NEVER switch to the new syntax. > > Using function assigned GUC is similar, but it is looking less robust - >> and some editors can forgot this information. >> > > If you forget then you get an error. Then you remember. > > Lot of issues we can solved by plpgsq.extra_error, extra_warnings - but >> probably not all - for example issue of FOUND variable or introducing >> new auto variable ROW_COUNT. PLpgSQL - PL/SQL is safe - it propose the >> statement GET DIAGNOSTICS, but I understand so isn't funny to write more >> and more GET DIAGNOSTICS rc = ROW_COUNT; So some shortcuts can be nice, >> but there is risk, so this shortcut breaks existing code, and the >> costs/benefits are individual. There cannot be 100% agreement ever. So >> some customisation should be good. >> > > That's the whole point of having settings to deal with incompatibilities: > so we can actually fix these warts without breaking everyone's code, yet > also make it clear to users that they should stop using the warts and > instead use the new and improved syntax.
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. 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) >
