fixed issue where the password was being assigned to wrong config key

[ap-in-git]

Previously when on DNS connection string when empty password was passed . It was being assigned to wrong config key.
For e.g host=localhost user=jack password= dbname=mydb port=5432 sslmode=disable used to generate password as dbname=mydb. This PR tries to fix this. Not sure if this would be right way to fix it though . All the tests were passing

[jackc]

This seems to have broken TestParseConfigDSNWithTrailingEmptyEqualDoesNotPanic. Also, just FYI, this is the pgconn used with pgx v4 not the current v5.

[ap-in-git]

I tried to fix TestParseConfigDSNWithTrailingEmptyEqualDoesNotPanic with the following piece of code

if len(s) == 0 || s[0] == ' ' && s[1] != '\'' { settings[key] = "" continue }

Then the final map of configs are generated correctly

The problem is now I get different set of error because now parsePort method is returning an error because the port value method becomes empty string

I wonder whether the test TestParseConfigDSNWithTrailingEmptyEqualDoesNotPanic should not panic on this case though

[jackc]

Actually, on further research this is not really a bug. We try to match psql and the C library libpq.

https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-CONNSTRING-KEYWORD-VALUE

To write an empty value, or a value containing spaces, surround it with single quotes

[ap-in-git]

Ah, I see then shouldn't TestParseConfigDSNWithTrailingEmptyEqualDoesNotPanic panic?

[jackc]

No, a bad conn string shouldn't be able to make the application panic. Though even calling it a bad string is not quite right. Spaces are allowed before and after the =. So there really is no way to know that password= port=5555 doesn't actually mean the password is port=5555.

[ap-in-git]

Oh okay. Thanks anyway for amazing library. I just ran into the issue. I guess I will put empty single quote then