From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Merlin Moncure <mmoncure(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Marko Tiikkaja <marko(at)joh(dot)to> |
Subject: | Re: merging some features from plpgsql2 project |
Date: | 2016-12-28 17:54:19 |
Message-ID: | 2240014a-181e-9403-f97a-ee87932b2118@BlueTreble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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)
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Nasby | 2016-12-28 17:54:23 | Re: merging some features from plpgsql2 project |
Previous Message | Pavel Stehule | 2016-12-28 17:30:05 | Re: proposal: session server side variables |