Re: [HACKERS] merging some features from plpgsql2 project

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)