Stephen Frost <sfr...@snowman.net> writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> It's not a "half measure", it's providing a sane upgrade path.
> I really don't see it that way. We're talking about existing scripts > which will break if the binary is renamed. That means that, today, > they're using createlang/createdb/createuser. The options for a user > using such a script with the proposed approach, when PG10 comes out > are: > 1) don't change the script, because the old names work > 2) adjust the script to work with both X and pg_X values You're neglecting what I think most people would want to do: 3) Wait till they no longer care about supporting versions that have only the old names, then change their scripts to use pg_X. > I anticipate an argument along the lines of "but we're giving them time > to make the change" but I don't see that as really holding all that much > weight either- we maintain back-branch releases for years to give users > time to adjust to changes that have been made in the latest releases. Yes, and that also means that other tooling has to be prepared to work with multiple releases. You're proposing to make that harder, and I do not think there's sufficient reason. This line of argument means that we probably couldn't remove the old names until 9.6 is out of support, but so what? We had the deprecation notice for createlang in place since 9.1, and I think that that's about the right timeline for this sort of changeover. We should not cavalierly break peoples' scripts for what's fundamentally just a cosmetic improvement. (Or in other words, we've been getting along fine with these script names for circa twenty years, so what's the rush to change them RIGHT NOW?) regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers