Robert Haas wrote:
> 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.
A compatibility extension sounds like a pretty decent idea to me,
considering this point. I think breakage without a workaround will
cause people to defer migration more than they otherwise would; the
extension gives them an easy way forward while they set up their
internal code to the new reality, to test the other new things in pg10.
If we keep the extension forever, so what? It's not like tsearch2
causes us too much of a maintenance pain. It's been patched a few
times, but only to change things that wouldn't need changes in a
xlog->wal aliases-only module. Anyway, I would mark the module as
deprecated with an intent of removing it in half a dozen releases or so.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
