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 20170319142524.GA9812@tamriel.snowman.net
Whole thread Raw
In response to Re: [HACKERS] Removing binaries (was: createlang/droplang deprecated)  (Magnus Hagander <magnus@hagander.net>)
Responses Re: [HACKERS] Removing binaries (was: createlang/droplang deprecated)  (Tom Lane <tgl@sss.pgh.pa.us>)
[HACKERS] Implementing delete in columnar store fdw  (Hari Krishnan <harikrishnanprabakaran@gmail.com>)
List pgsql-hackers
* Magnus Hagander (magnus@hagander.net) wrote:
> On Sat, Mar 18, 2017 at 9:23 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Magnus Hagander <magnus@hagander.net> writes:
> > > createuser, dropuser - definitely pollutes the namespace, people do
> > > sometimes try them for the wrong thing. Unlike the db ones they do add
> > > value though -- I don't think we have a psql way of in a single command
> > > doing what --pwprompt on createuser does, do we? But given that we are in
> > > the process of breaking a lot of other scripts for 10, perhaps we should
> > > rename it to pg_createuser?
> >
> > I'm not particularly on board with arguments like "we already broke a ton
> > of stuff so let's break some more".  Eventually you've managed to create
> > a daunting barrier to upgrading at all.
>
> The argument is more that if we are going to break it, now is a good time
> to do it because we are already forcing people to review their scripts.
>
> If we decide not to break it at all that's one thing. But if we *are* going
> to break it, it's better to do it in 10 than in 11.

I tend to agree with this, but...

> > 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.  They don't do anything
for the namespace pollution problem and even if we do spit out a warning
or something (which may break things *anyway*, as you suggest), it's
just delaying when things break to some future point where we'll have to
argue, again, about removing the symlinks, and then it'll be in PG11 or
PG12 or some other release which isn't breaking as much.

> > Maybe we should handle createdb likewise, rather than just kicking it to
> > the curb.  I know I use it quite often; it's less typing than psql -c
> > 'create database ...' postgres, and still would be with a pg_ prefix.
>
> As long as they have a pg_ prefix, I don't see much harm in them being
> there, they're tiny. It's not like they're a huge maintenance burden.

I agree with keeping them, with a pg_ prefix.

Thanks!

Stephen

pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: [HACKERS] Removing binaries (was: createlang/droplang deprecated)
Next
From: Greg Stark
Date:
Subject: Re: [HACKERS] [PATCH] SortSupport for macaddr type