* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost <sfr...@snowman.net> writes: > > * Magnus Hagander (mag...@hagander.net) wrote: > >> On Sat, Mar 18, 2017 at 9:23 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >>> I think a more reasonable way to proceed is to install symlinks > >>> pg_createuser -> createuser (or the other direction), mark the older names > >>> as deprecated, and announce that we'll remove the old names a few releases > >>> from now. That gives people time to adjust. > > >> I'd suggest doing it in the other direction, but yeah, that seems like a > >> softer way to handle it. As long as we clearly document them as such. > >> Perhaps we should even have them output a little "hey you should be using > >> pg_xyz" if they are used by the wrong name, but I wonder if that might > >> break things. > > > I don't really agree with these half-measures. > > 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 If option #1 is used, then it's just going to break whenever we do remove those symlinks, meaning all we're doing is delaying things without very much point. If option #2 is used, which I believe is what we would want people to do, then the symlinks are useless. 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. The people who are going to rush out to deploy PG10 as soon as it's released with the expectation that nothing is going to break aren't very likely going to be the group who will be reading the release notes carefully and making note of the changes we made that impact their environment and scripts. In other words, they're likely to stick with option #1 above, and complain loudly whenever we do remove the symlinks, if we ever manage to. > If we had not had the deprecation notice in place for createlang, I do > not think Magnus' proposal to remove it would have been accepted so > easily --- or, probably, at all. There is no such notice in place > for createdb or createuser, so arguing by analogy to that proposal > falls flat. I wasn't. Thanks! Stephen
signature.asc
Description: Digital signature
