Re: [HACKERS] Removing binaries

On Tue, Mar 28, 2017 at 6:44 PM, Robert Haas wrote: > On Tue, Mar 28, 2017 at 12:18 PM, Tom Lane wrote: > > Robert Haas writes: > >> On Tue, Mar 28, 2017 at 11:44 AM, Peter Eisentraut > >>

Re: [HACKERS] Removing binaries

Robert Haas writes: > On Tue, Mar 28, 2017 at 12:18 PM, Tom Lane wrote: >> Perhaps we could satisfy novices by changing the out-of-the-box >> behavior, but provide some way to select the old behavior for >> installations that are really depending on it.

Re: [HACKERS] Removing binaries

On Tue, Mar 28, 2017 at 12:18 PM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Mar 28, 2017 at 11:44 AM, Peter Eisentraut >> wrote: >>> On 3/21/17 08:12, Robert Haas wrote: I think a big part of the usability

Re: [HACKERS] Removing binaries

Robert Haas writes: > On Tue, Mar 28, 2017 at 11:44 AM, Peter Eisentraut > wrote: >> On 3/21/17 08:12, Robert Haas wrote: >>> I think a big part of the usability problem here comes from the fact >>> that the default database for

Re: [HACKERS] Removing binaries

On Tue, Mar 28, 2017 at 11:44 AM, Peter Eisentraut wrote: > On 3/21/17 08:12, Robert Haas wrote: >> I think a big part of the usability problem here comes from the fact >> that the default database for connections is based on the username, >> but the default

Re: [HACKERS] Removing binaries

On 3/21/17 08:12, Robert Haas wrote: > I think a big part of the usability problem here comes from the fact > that the default database for connections is based on the username, > but the default databases that get created have fixed names (postgres, > template1). So the default configuration is

Re: [HACKERS] Removing binaries

On Tue, Mar 21, 2017 at 10:43 AM, David Steele wrote: > I suppose it would be too big a change to have psql try the username and > then fallback to postgres on failure? It's not so much that the change would be too big as that the resulting semantics would be confusing, at

Re: [HACKERS] Removing binaries

On 3/21/17 10:30 AM, David G. Johnston wrote: On Tue, Mar 21, 2017 at 5:12 AM, Robert Haas >wrote: Here's another idea: what if we always created the default database at initdb time? For example, if I initdb as rhaas, maybe it

Re: [HACKERS] Removing binaries

On Tue, Mar 21, 2017 at 5:12 AM, Robert Haas wrote: > > Here's another idea: what if we always created the default database at > initdb time? For example, if I initdb as rhaas, maybe it should > create an "rhaas" database for me, so that this works: > > initdb > pg_ctl

Re: [HACKERS] Removing binaries

On Mon, Mar 20, 2017 at 6:15 PM, David Steele wrote: > On 3/20/17 3:40 PM, Jan de Visser wrote: >> On Monday, March 20, 2017 3:30:49 PM EDT Robert Haas wrote: >>> That would annoy me, because I use these constantly. I also think >>> that they solve a problem for users, which

Re: [HACKERS] Removing binaries

On 3/20/17 3:40 PM, Jan de Visser wrote: 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

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

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*

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

* 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

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

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

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

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

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

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

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

* 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

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

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

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

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

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

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

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

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

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

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

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

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