From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | 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>, Magnus Hagander <magnus(at)hagander(dot)net> |
Subject: | Re: Removing binaries |
Date: | 2017-03-28 16:44:43 |
Message-ID: | CA+TgmoaanJhjExUQXeO7mPcj1O6LtGOV6PCQRXTB7cv=_HciSg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
If initdb created the database that you currently have to create as a
separate step by running 'createdb', I bet we'd eliminate a metric
buttload of new user confusion and harm almost nobody. Anybody who
doesn't want that extra database can just drop it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Page | 2017-03-28 16:47:04 | Re: Monitoring roles patch |
Previous Message | Fujii Masao | 2017-03-28 16:33:55 | Re: [COMMITTERS] pgsql: Allow vacuums to report oldestxmin |