Re: Removing binaries - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Removing binaries
Date
Msg-id 16139.1490722453@sss.pgh.pa.us
Whole thread Raw
In response to Re: Removing binaries  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Mar 28, 2017 at 12:18 PM, Tom Lane <tgl@sss.pgh.pa.us> 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 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?

What "default database"?  Are you suggesting that createuser should
forcibly create a similarly-named database?  Doesn't sound like a
great idea to me; it's presuming what seems like minority usage.

If we were to do anything about this, my sketch of a desirable solution
would be to invent a GUC named something like "default_database", which
would specify the DB to connect to when the incoming request packet
doesn't name one.  We could have it be "postgres" out of the box, but
allow the value "$user" to select the old behavior.

However ... a little bit of research shows that this behavior is wired
into libpq as well as the backend, and that therefore the backend's
code path that inserts the username as the default DB name is dead
code (at least when processing libpq-driven connection requests;
I don't know what JDBC and other client libraries do).  This means
that there isn't any really centralized way to fix it.  We could
delete that behavior from libpq easily enough, but then we'd have
a situation where the behavior varies depending on which version of
which client library you're using.

I'm afraid now that changing this would be far more pain than it
could possibly be worth.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Pavan Deolasee
Date:
Subject: Re: Patch: Write Amplification Reduction Method (WARM)
Next
From: Shubham Barai
Date:
Subject: GSoC 2017 Proposal for "Explicitly support predicate locks in indexaccess methods besides btree"