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