* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > * Magnus Hagander (magnus@hagander.net) wrote:
> >> On Sat, Mar 18, 2017 at 9:23 PM, Tom Lane <tgl@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
