** The real problem is that we have no mechanism for allowing a PL's language/syntax/API to move forward without massive backwards compatibility problems. **
I wanted to break this out separately, because IMO it's the real heart of the matter.
I think it would be silly not to allow a global setting of compatibility. You certainly don't want to force people to stick magic keywords in their code forevermore.
To that end, would GUCs be a workable answer here? That should give you the ability to control incompatibilities at a function, user, database and global level. It would also allow you to chose between raising a WARNING vs a FATAL.
GUC are fragile - the source code and settings can be separated.
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.
Using function assigned GUC is similar, but it is looking less robust - and some editors can forgot this information.
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.
I realize we've had some bad experiences with compatibility GUCs in the past, but I'd argue we've also had some good experiences. I see that add_missing_from is now completely gone, for example, presumably with no complaints. There's probably several other compatibility GUCs we could remove now.
-- 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)