Tie default DB name to database user name

[solidsnack]

The previous behaviour was at variance with the native client behaviour, per:

https://www.postgresql.org/docs/10/static/libpq-connect.html#LIBPQ-PARAMKEYWORDS

The database name. Defaults to be the same as the user name.
In certain contexts, the value is checked for extended formats...

[solidsnack]

I am really not sure about the test 'modified values are passed to created clients' in test/integration/client/configuration-tests.js, with regards to setting defaults.database.

• Maybe the ability to set defaults.database should be removed? It's not clear how to reconcile it with the behavior of libpq, "Defaults to be the same as the user name.". Maybe it should only take effect if no username is set?

• I'm not sure I understand the use case for the defaults.

The motivation for this patch, is that we have some DATABASE_URLs set across our infra that rely on the libpq behavior, that is also broadly compatible with other Postgres clients. I'm sure many other people are in the same situation.

It seems like something changed here, perhaps in the way Knex uses node-postgres, because these URLs used to work fine with our Node applications, too.

[charmander]

Note that this is a breaking change for anything setting or relying on pg.defaults.database.

[charmander]

Is it possible for this.user to be falsy?

[solidsnack]

Looking at the implementation, it's set with val('user', config) which can be false when (a) there is no default set and (b) the corresponding environment variable is not set.

From the outside, URLs like postgres:/// don't have a user, so it stands to reason the implementation has to allow it to be falsey.

[charmander]

The default has to be set to something; if it’s undefined, the connection is going to fail anyway. I think this can just be const getDefaultDatabase = () => this.user. (At that point, it doesn’t even need to be a function – this.user can be passed in directly.)

[solidsnack]

Note that this is a breaking change for anything setting or relying on pg.defaults.database.

Perhaps there is some intermediate possible?

The current behavior is such that node-postgres interprets Postgres URLs in a manner different from libpq and other implementations. I guess the first question to answer is: is that something we're okay with or would we like to see Postgres URLs work the same with Node apps as they do with things like psql and psycopg2?

[charmander]

A breaking change just means it needs a major version increment.

[solidsnack]

Maybe if we allowed defaults.database to be a function as well as a string, this could be a point release.

• If it is not set, use the username.
• If it is a string, use the string.
• If it is a function, pass the parsed connection info into the function.

[brianc]

I will merge this as soon as I cut the next major version. Sorry for the delay.

[brianc]

Actually looks like 1679 supersedes this, so closing in favor of that one.