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
> >> wrote:
> >>> On 3/21/17 08:12, Robert Haas wrote:
> I think a big part of the usability problem here
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.
> Hmm. I guess that would mean that the s
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 problem here comes from the fact
that the default database for connection
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 connections is based on the username,
>>> but the default databases
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 databases that get created have fixed n
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 o
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 least IMHO. Imagine:
On 3/21/17 10:30 AM, David G. Johnston wrote:
On Tue, Mar 21, 2017 at 5:12 AM, Robert Haas mailto:robertmh...@gmail.com>>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" d
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 start
> psql
>
> I think a
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 is this:
>>>
>>> [rha
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 said, do they add any
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 yo
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 sug
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 p
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 warni
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 bin
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 o
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
> >
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 fli
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
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
* 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.
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
* 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),
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 anno
* 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 -
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 comman
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
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 th
On 03/18/2017 01:12 PM, Magnus Hagander wrote:
Magnus Hagander mailto:mag...@hagander.net>> writes:
2017-03-18 14:00 GMT+01:00 Peter Eisentraut mailto:peter.eisentr...@2ndquadrant.com>>:
createuser, dropuser - definitely pollutes the namespace, people do
sometimes try them for the wrong thing
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 gi
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
32 matches
Mail list logo
