Re: Removing binaries
От | Robert Haas |
---|---|
Тема | Re: Removing binaries |
Дата | |
Msg-id | CA+TgmoaanJhjExUQXeO7mPcj1O6LtGOV6PCQRXTB7cv=_HciSg@mail.gmail.com обсуждение исходный текст |
Ответ на | [HACKERS] Removing binaries (was: createlang/droplang deprecated) (Magnus Hagander <magnus@hagander.net>) |
Ответы |
Re: Removing binaries
(Tom Lane <tgl@sss.pgh.pa.us>)
Re: Removing binaries (Magnus Hagander <magnus@hagander.net>) |
Список | pgsql-hackers |
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 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
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Fujii MasaoДата:
Сообщение: Re: [COMMITTERS] pgsql: Allow vacuums to report oldestxmin