Re: [HACKERS] Removing binaries (was: createlang/droplang deprecated)

[Jan de Visser]

On Monday, March 20, 2017 3:30:49 PM EDT Robert Haas wrote:
> On Sat, Mar 18, 2017 at 4:12 PM, Magnus Hagander  
wrote:
> > createdb, dropdb - also not clear they're about postgres, more likely to
> > be
> > used by mistake but not that bad. That said, do they add any *value*
> > beyond
> > what you can do with psql -c "CREATE DATABASE"? I don't really see one, so
> > I'd suggest dropping these too.
> 
> That would annoy me, because I use these constantly.  I also think
> that they solve a problem for users, which is this:
> 
> [rhaas ~]$ psql
> psql: FATAL:  database "rhaas" does not exist
> [rhaas ~]$ psql -c 'create database rhaas;'
> psql: FATAL:  database "rhaas" does not exist
> [rhaas ~]$ gosh, i know i need to connect to a database in order to
> create the database to which psql tries to connect by default, so
> there must be an existing database with some name, but what exactly is
> that name, anyway?
> -bash: gosh,: command not found
> 
> There was an occasion when this exact problem almost caused me to give
> up on using PostgreSQL.  Everybody here presumably knows that
> template1 and postgres are the magic words you can add to the end of
> that command line to make it work, but that is NOT self-evident to
> newcomers.

Same here. I worked on a system with a shrink-wrap installer which installed 
pgsql as well and initialized it for use by the system user of our software. 
If a tester or sales engineer wanted to play with the DB, it would be about 30 
minutes before they would end up at my desk, in tears.


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Removing binaries (was: createlang/droplang deprecated)

[Robert Haas]

On Sat, Mar 18, 2017 at 4:12 PM, Magnus Hagander  wrote:
> createdb, dropdb - also not clear they're about postgres, more likely to be
> used by mistake but not that bad. That said, do they add any *value* beyond
> what you can do with psql -c "CREATE DATABASE"? I don't really see one, so
> I'd suggest dropping these too.

That would annoy me, because I use these constantly.  I also think
that they solve a problem for users, which is this:

[rhaas ~]$ psql
psql: FATAL:  database "rhaas" does not exist
[rhaas ~]$ psql -c 'create database rhaas;'
psql: FATAL:  database "rhaas" does not exist
[rhaas ~]$ gosh, i know i need to connect to a database in order to
create the database to which psql tries to connect by default, so
there must be an existing database with some name, but what exactly is
that name, anyway?
-bash: gosh,: command not found

There was an occasion when this exact problem almost caused me to give
up on using PostgreSQL.  Everybody here presumably knows that
template1 and postgres are the magic words you can add to the end of
that command line to make it work, but that is NOT self-evident to
newcomers.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Removing binaries (was: createlang/droplang deprecated)

[Peter Eisentraut]

On 3/18/17 16:12, Magnus Hagander wrote:
> But given that we are in the process of breaking a lot of other scripts
> for 10,

I don't think the xlog renaming really affects this area.

> perhaps we should rename it to pg_createuser?

I'm not keen on doing that now, but if we were to do it at some point, I
would do it for all programs not already starting with "p" or containing
"pg".

-- 
Peter Eisentraut  http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Removing binaries (was: createlang/droplang deprecated)

[Joshua D. Drake]

On 03/19/2017 01:01 PM, Tom Lane wrote:

Andreas Karlsson  writes:

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.


It seems reasonably trivial to me as far as the code goes --- just
create a symlink during installation.  (On Windows I suppose we'd have
to make a second physical copy, but these files are not so large that
that seems unacceptable.)


Windows supports symlinks:

https://msdn.microsoft.com/en-us/library/windows/desktop/aa365680(v=vs.85).aspx

JD


--
Command Prompt, Inc.  http://the.postgres.company/
+1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.
Unless otherwise stated, opinions are my own.


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Removing binaries (was: createlang/droplang deprecated)

[Tom Lane]

Andres Freund  writes:
> I wish 'pg' wasn't an already used binary name.  It'd be much nicer if
> we had a '/usr/bin/pg' wrapper binary in the git style, that we could easily
> expand over time, without hitting new conflicts.  I'd even consider a
> '/usr/bin/pgsql' that has commands for all our binaries a considerable
> improvement in the long term.

Meh.  I'm not seeing where "pg command args" is that much superior to
"pg_command args".  Yeah, if we'd done it like that from the beginning
it'd be fine; but people are used to the latter style and I don't feel
a need to make them change over.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Removing binaries (was: createlang/droplang deprecated)

[Tom Lane]

Stephen Frost  writes:
> If we take your approach to its logical conclustion then we should be
> planning to maintain all user-facing deprecated features for as long as
> there is a version where it exists in a non-deprecated fashion, in other
> words for 5 years, if we assume that script authors only care about
> supporting as far back as we do, which I'm not entirely sure is a great
> assumption to begin with, but I'd say it's at least a minimum.

Well, that is definitely a straw man (as you admit later).  I don't want
to go there either.  Where to draw the line has to be a case-by-case
decision, though.  In this case the amount of effort involved in providing
backwards compatibility is pretty minimal, and the project has failed to
provide any warning to users that this is something we might choose to
break in future, so it seems to me that we ought to provide compatibility
for awhile.  If somebody bitches that we broke their script in v15, we'll
be in a much better position if we can point to five years' worth of
deprecation notices than if we just have to say "tough, we felt like
breaking your script so we did it".

> I'll admit that part of that is likely because I don't think I have
> *ever* used createdb or createlang or createuser (excepting whatever
> regression tests run them),

Well, personally I use createdb pretty often.  I basically never use
the other two, but I don't fool myself that I'm a representative user.
createuser in particular seems like it has pretty high value-added
if you create new roles often and need to give them passwords.  Yeah,
you can do it in psql, but it's not as convenient, especially if you
want to do proper quoting.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Removing binaries (was: createlang/droplang deprecated)

[Andres Freund]

On 2017-03-18 16:23:17 -0400, Tom Lane wrote:
> Magnus Hagander  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.

+1


> 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.

+1


> 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.

I think we should add pg_createdb, and do a normal deprecation cycle for
removing createdb.


I wish 'pg' wasn't an already used binary name.  It'd be much nicer if
we had a '/usr/bin/pg' wrapper binary in the git style, that we could easily
expand over time, without hitting new conflicts.  I'd even consider a
'/usr/bin/pgsql' that has commands for all our binaries a considerable
improvement in the long term.


Greetings,

Andres Freund


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Removing binaries (was: createlang/droplang deprecated)

[Tom Lane]

Andreas Karlsson  writes:
> 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.

It seems reasonably trivial to me as far as the code goes --- just
create a symlink during installation.  (On Windows I suppose we'd have
to make a second physical copy, but these files are not so large that
that seems unacceptable.)  It might be more work on the documentation
side, depending on whether you wanted two copies of the man page or
not.  I see that postmaster's man page pretty much just points to
postgres, so it seems like we could do that for these scripts too.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Removing binaries (was: createlang/droplang deprecated)

[Stephen Frost]

Greetings,

* Andreas Karlsson (andr...@proxel.se) wrote:
> On 03/19/2017 07:35 PM, Stephen Frost wrote:
> >* Tom Lane (t...@sss.pgh.pa.us) wrote:
> >>Stephen Frost  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


signature.asc
Description: Digital signature

Re: [HACKERS] Removing binaries (was: createlang/droplang deprecated)

[Andreas Karlsson]

On 03/19/2017 07:35 PM, Stephen Frost wrote:

* Tom Lane (t...@sss.pgh.pa.us) wrote:

Stephen Frost  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.


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.


Andreas



--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Removing binaries (was: createlang/droplang deprecated)

[Stephen Frost]

* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost  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.

Perhaps it's a bit stark, but my experience has been that people tend to
fall into one of the two camps I outlined above.

If we take your approach to its logical conclustion then we should be
planning to maintain all user-facing deprecated features for as long as
there is a version where it exists in a non-deprecated fashion, in other
words for 5 years, if we assume that script authors only care about
supporting as far back as we do, which I'm not entirely sure is a great
assumption to begin with, but I'd say it's at least a minimum.

To that I say: heck no.  I understand that there has been grief due to
the various user-facing changes we've made recently and I completely
understand those complaints because it means that developers have to
deal with version-specific differences, particularly when it comes to
monitoring and now with the pg_xlog -> pg_wal changes, more with backup
too, but trying to deal with multiple sets of interfaces over a long
period of time is going to be incredibly painful and very confusing for
users, especially new users.

In some cases, we would end up with 5 interfaces, all having to be
maintained across all of the back-branches, because we changed something
in every release, deprecating each prior version as we went.

No, I don't feel that this kind of backwards-compatibility is really
something we want, as a project.  We, for very good reason, support 5
years worth of back-branches to allow users the opportunity and time to
migrate at a reasoned pace, possibly even skipping versions as they go
if they don't wish to make changes every year.

I'll admit that this is a bit of a straw-man and goes beyond what you're
suggesting here, specifically, but that just begs the question of "where
do we draw the line", if we are going to draw one.  Are scripts which
use command-line utilities more of an issue to break than those which
query pg_stat_activity?

> > 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.

I do think, in the general sense, that tools based on PG should be
prepared to deal with differences between major versions, because we
have quite a few of those.  I'm hard-pressed to come up with a major PG
tool which *doesn't* have mechanisms for dealing with differences
between major versions already.

There's certainly no shortage of PG-based applications which also have
code for dealing with different PG major versions either.

> 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.

Per my question above- when is 5 years of deprecated-but-working support
for a feature the right timeline and when isn't it?  My feeling is that
most of the changes we make in this regard are accepted under the "well,
it's a major version change, so you'll need to adjust" but this change
isn't viewed in that same light and I'm not really sure that I see a
good reason for that.

I'll admit that part of that is likely because I don't think I have
*ever* used createdb or createlang or createuser (excepting whatever
regression tests run them), but even so, figuring out some idea where we
draw this line between things that need to be deprecated for 5 years and
things that don't would be useful, though likely a source of ongoing
discussion too.

> (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 

Re: [HACKERS] Removing binaries (was: createlang/droplang deprecated)

[Tom Lane]

Stephen Frost  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 (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Removing binaries (was: createlang/droplang deprecated)

[Stephen Frost]

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

Re: [HACKERS] Removing binaries (was: createlang/droplang deprecated)

[Tom Lane]

Stephen Frost  writes:
> * Magnus Hagander (mag...@hagander.net) wrote:
>> On Sat, Mar 18, 2017 at 9:23 PM, Tom Lane  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.

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.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Removing binaries (was: createlang/droplang deprecated)

[Stephen Frost]

* Magnus Hagander (mag...@hagander.net) wrote:
> On Sat, Mar 18, 2017 at 9:23 PM, Tom Lane  wrote:
> > Magnus Hagander  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


signature.asc
Description: Digital signature

Re: [HACKERS] Removing binaries (was: createlang/droplang deprecated)

[Magnus Hagander]

On Sat, Mar 18, 2017 at 9:23 PM, Tom Lane  wrote:

> Magnus Hagander  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 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.


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.

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Re: [HACKERS] Removing binaries (was: createlang/droplang deprecated)

[Magnus Hagander]

On Sun, Mar 19, 2017 at 1:44 PM, Andreas Karlsson  wrote:

> On 03/18/2017 09:12 PM, Magnus Hagander wrote:
>
>> createdb, dropdb - also not clear they're about postgres, more likely to
>> be used by mistake but not that bad. That said, do they add any *value*
>> beyond what you can do with psql -c "CREATE DATABASE"? I don't really
>> see one, so I'd suggest dropping these too.
>>
>
> The value they add is that they quote the database name and options
> correctly which makes them easier to use safely and reliably in shell
> scripts. And unless I am missing something obvious I do not think there is
> any easy way for a beginner to do this with just psql.


Good point, I hadn't thought of that. I guess I just generally make sure I
don't use names that require quoting myself, but I can definitely see how
that's an actual value-add.

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Re: [HACKERS] Removing binaries (was: createlang/droplang deprecated)

[Andreas Karlsson]

On 03/18/2017 09:12 PM, Magnus Hagander wrote:

createdb, dropdb - also not clear they're about postgres, more likely to
be used by mistake but not that bad. That said, do they add any *value*
beyond what you can do with psql -c "CREATE DATABASE"? I don't really
see one, so I'd suggest dropping these too.


The value they add is that they quote the database name and options 
correctly which makes them easier to use safely and reliably in shell 
scripts. And unless I am missing something obvious I do not think there 
is any easy way for a beginner to do this with just psql.


Andreas


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Removing binaries (was: createlang/droplang deprecated)

[Joshua D. Drake]

On 03/18/2017 01:12 PM, Magnus Hagander wrote:

Magnus Hagander > writes:

2017-03-18 14:00 GMT+01:00 Peter Eisentraut >:



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?


We have one chance in the near future to shake things up, break things 
for the better and lose a lot of long time issues. Making things 
consistent and declarative (pg_ for example) is a great opportunity.


+1

JD


--
Command Prompt, Inc.  http://the.postgres.company/
+1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Removing binaries (was: createlang/droplang deprecated)

[Tom Lane]

Magnus Hagander  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.

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.

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.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Removing binaries (was: createlang/droplang deprecated)

[Magnus Hagander]

Magnus Hagander  writes:
>> 2017-03-18 14:00 GMT+01:00 Peter Eisentraut <
peter.eisentr...@2ndquadrant.com>:
>>> I just noticed that createlang and droplang have been listed as
>>> deprecated since PG 9.1.
>>> Do we dare remove them?

> (I'd extend it to all the non-prefixed pg binaries, but let's open that
can
> of worms right now, one thing at a time)

> To my mind, these two and createuser/dropuser are the only really serious
> namespacing problems among our standard binaries.  The ones with names
> ending in "db" don't seem likely to cause huge confusion.  I suppose that
> if we were naming it today, "psql" wouldn't get that name; but the chances
> of renaming that one are certainly zero, namespace conflict or no.

> But createuser/dropuser are a real problem, because they certainly could
> be mistaken for system-level utilities.

Yeah, I've seen people use those and get quite confused. Luckily they don't
tend to *break* things, but it's definitely namespace pollution.

If we look through the binaries we have now that are not prefixed with pg_:

clusterdb, vacuumdb, reindexdb - while not clear that they are about
*postgres*, it's pretty clear they're about a database. I wouldn't name
them without pg_ today, but I doubt it's worth chaning. They also add
actual value (being able to process multiple things)

createdb, dropdb - also not clear they're about postgres, more likely to be
used by mistake but not that bad. That said, do they add any *value* beyond
what you can do with psql -c "CREATE DATABASE"? I don't really see one, so
I'd suggest dropping these too.

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?

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/