On Thu, Jan 12, 2017 at 1:12 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Vladimir Rusinov <vrusinov@google.com> writes:
>> On Thu, Jan 12, 2017 at 4:57 PM, Euler Taveira <euler@timbira.com.br> wrote:
>>> As Robert suggested in the other email: extension to create old names.
>
>> I don't follow the reasoning for the extension. It seem to have downsides
>> of both alternatives combined: we still break people's code, and we add
>> even more maintenance burden than just keeping aliases.
>
> Yeah, I'm not terribly for the extension idea. Robert cited the precedent
> of contrib/tsearch2, but I think the history of that is a good argument
> against this: tsearch2 is still there 9 years later and there's no
> indication that we'll ever get rid of it. We can let things rot
> indefinitely in core too. If we do ever agree to get rid of the aliases,
> stripping them out of pg_proc.h will not be any harder than removing
> a contrib directory would be.
From a technical point of view, that is pretty much true. But from a
user perspective, I don't think it is. If the old names live in an
extension, then they will not be there by default. Tools and scripts
will break. If that's a problem for a particular user, they an
install the extension to unbreak those things, but tool authors will
probably be motivated to upgrade their tools so that the extension is
no longer needed. Therefore, if we eventually drop the extension,
there will probably be few users relying on it at that point. On the
other hand, if we install aliases that are present in every install -
and that are not even optionally removable - a lot of people are not
going to bother using the new names at all. They'll just keep on
using the old ones so that their tools work with both old and new
versions, and if we eventually rip the stuff out of pg_proc.h it will
cause almost as much howling as if we'd done it right at the
beginning.
In other words, adding an extension is the only option that I see
which will give tool authors a strong incentive to support the new
names without making it a hard requirement on day one.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
