Re: [HACKERS] Removing binaries (was: createlang/droplang deprecated) - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: [HACKERS] Removing binaries (was: createlang/droplang deprecated)
Date
Msg-id 20170319195529.GD9812@tamriel.snowman.net
Whole thread Raw
In response to Re: [HACKERS] Removing binaries (was: createlang/droplang deprecated)  (Andreas Karlsson <andreas@proxel.se>)
List pgsql-hackers
Greetings,

* Andreas Karlsson (andreas@proxel.se) wrote:
> On 03/19/2017 07:35 PM, Stephen Frost wrote:
> >* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> >>Stephen Frost <sfrost@snowman.net> writes:
> >>(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?)
> >
> >To be clear, I'm not in any particular rush to change them 'RIGHT NOW'.
> >I tend to agree with Magnus that we're doing a lot of other things in
> >PG10 and that makes it a bit of a natural point, but I don't hold that
> >position terribly strongly.  On the other hand, I do not relish the idea
> >of providing backwards-compatibility for every user-facing change we do
> >for 5 years and that's where I feel this approach is encouraging us to
> >go.
>
> I only think that argument is only applicable where the changes are
> closely related, e.g. renaming pg_clog, pg_xlog and pg_log in the
> same release. I do not see any strong connection between createuser
> and pg_xlog.

Given all that we're doing, it strikes me as pretty likely that people
will realize that PG10 does more and will therefore pay more attention,
in general, to what we tell them in the release notes about changes.

> As for if we should have backwards compatibility for the old names I
> am leaning weakly for providing it in the case of createuser. I can
> see end users being pissed off that the createuser command is
> suddenly gone without any warning when they upgrade. On the flip
> side I have no idea how much work it would be to maintain those
> legacy names.

This particular case might not be that much of a maintenance burden, but
to your example above, if they're going to be annoyed about it going
missing in PG10, it seems likely that they're going to be annoyed when
the symlink goes away in PG15 (or whatever) too.

Either way, we'll obviously document what we're doing in the release
notes, so the whole "without any warning" doesn't really fly, in my
view, either.

Thanks!

Stephen

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Re: Improve OR conditions on joined columns (common star schema problem)
Next
From: Alvaro Herrera
Date:
Subject: Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands:\quit_if, \quit_unless)