On Thu, Jan 12, 2017 at 1:12 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Vladimir Rusinov <vrusi...@google.com> writes: >> On Thu, Jan 12, 2017 at 4:57 PM, Euler Taveira <eu...@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 -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers