Doesn't respect host in query parameters

[LinusU]

Currently the following connection string doesn't get parsed properly:

postgresql:///test?host=%2Ftmp%2Fephemeralpg.goZMBg

It was generated by the tool ephemeralpg and seems to work with other client...

[tym-xqo]

I was just coming in here to note more or less the same issue. It is not just ephemeralpg; there are many cases for connecting to Postgres via unix domain sockets, and using the host parameter is the standard way to do this, according to PostgreSQL docs: https://www.postgresql.org/docs/current/static/libpq-connect.html#LIBPQ-PARAMKEYWORDS

For now, you can work around this using the socket: protocol, as described here brianc/node-postgres#487

socket: doesn't seem to me to be standard, however, and has other limitations, such as expecting database username and password to match the local unix environment.

I am thinking about a PR to better address host querystring support and configuring socket connections in a way that conforms to Postgres documentation. I wanted to see first if there would be enough interest in doing so? Feedback appreciated.

@monteslu What do you think?

[vitaly-t]

b.t.w., the generic connection-string parses it fine.

@tym-oao

I am thinking about a PR to better address host querystring support and configuring socket connections in a way that conforms to Postgres documentation. I wanted to see first if there would be enough interest in doing so

I'm trying to get the driver to switch over to the generic connection-string, which doesn't have the issues described here.

See the related issues:

• Wiki: generic connection-string brianc/node-postgres#1667
• Support for multiple hosts brianc/node-postgres#1470

If it finally happens, then pg-connection-string can finally retire.

[vitaly-t]

This PR will fix it, if merged.

And if that address represents a socket, then changing it into this:

postgresql:///test?socket=%2Ftmp%2Fephemeralpg.goZMBg

will result in the host being set automatically:

{
    database: 'test',
    host: '/tmp/ephemeralpg.goZMBg'
}

And if your socket address complies with standard socket addresses, ending with .sock, then you will be able to make use of the secondary syntax, where such address is specified as the URL host:

'%2Ftmp%2Fephemeralpg.sock'
// {host: '/tmp/ephemeralpg.sock'}

'%2Ftmp%2Fephemeralpg.sock/test'
// {database: 'test', host: '/tmp/ephemeralpg.sock'}

[hjr3]

I believe this has been fixed in #34