Re: Removing binaries - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: Removing binaries
Date
Msg-id CABUevEyKe+cLu+=a5MOUriTvzUAKmQLakWkM7ae0L422DsrR8A@mail.gmail.com
Whole thread Raw
In response to Re: Removing binaries  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers


On Tue, Mar 28, 2017 at 6:44 PM, Robert Haas <robertmhaas@gmail.com> wrote:
On Tue, Mar 28, 2017 at 12:18 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Tue, Mar 28, 2017 at 11:44 AM, Peter Eisentraut
>> <peter.eisentraut@2ndquadrant.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.


--

pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: [PATCH] Incremental sort
Next
From: Alvaro Herrera
Date:
Subject: Re: Patch: Write Amplification Reduction Method (WARM)