On 12/28/16 7:16 AM, Pavel Stehule wrote:
** 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. **We have not, but there are few possibilities: 1. enhance #option command 2. we can introduce PRAGMA command https://en.wikipedia.org/wiki/Ada_(programming_language)#Pragmas <https://en.wikipedia.org/wiki/Ada_%28programming_language%29#Pragmas>
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.
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) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
