From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, David Steele <david(at)pgmasters(dot)net>, Jan de Visser <jan(at)de-visser(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Removing binaries |
Date: | 2017-03-28 21:26:19 |
Message-ID: | CABUevEyKe+cLu+=a5MOUriTvzUAKmQLakWkM7ae0L422DsrR8A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Mar 28, 2017 at 6:44 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Tue, Mar 28, 2017 at 12:18 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> >> On Tue, Mar 28, 2017 at 11:44 AM, Peter Eisentraut
> >> <peter(dot)eisentraut(at)2ndquadrant(dot)com> 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 names (postgres,
> >>>> template1). So the default configuration is one where you can't
> >>>> connect. Why the heck do we do it that way?
> >
> >>> Historical, probably. We could ponder changing the way the default
> >>> database is determined, but I don't want to imagine the breakage coming
> >>> out of that.
> >
> >> What do you think would break?
> >
> > Any configuration depending on the existing default?
> >
> > The existing behavior here dates from before we had schemas, so that
> > if users wanted to have private objects they *had* to use separate
> > databases. Nowadays a schema-per-user within one database makes a lot
> > more sense for many environments, and we even have the default value
> > for search_path set up to make that as painless as possible. Still,
> > it's not a solution for everybody, particularly not installations
> > that want to keep their users well separated.
> >
> > 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 same connection string would
> mean something different depending on how you configured this
> behavior, which does not sound like a good idea. But why not go the
> other way and just create the default database by default, either in
> addition to or instead of the postgres database? I mean, most people
> probably do this:
>
> initdb
> pg_ctl start
> createdb
>
I would argue that only a very small minority does that. The majority does
one of:
yum install postgresql
setup-postgresql <can't remember the switch offhand, but the one that calls
initdb for them>
systemctl start postgresql
or
apt-get install postgresql
(which auto-initdb's and autostarts)
or
double-clicks graphical installer on windows
(which auto-initdb's and autostarts)
I would bet each one of those have at least one and probably more than one
order of magnitude more users than ever call initdb or pg_ctl manually.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2017-03-28 22:12:03 | Re: Patch: Write Amplification Reduction Method (WARM) |
Previous Message | Alexander Korotkov | 2017-03-28 21:17:02 | Re: [PATCH] Incremental sort |