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

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:

Reply via email to