Postgres sslmode parameter support

[charlie-wasp]

I can't figure out clearly, is sslmode parameter supported for connection strings? As I can see in pg-connection-string, sslmode isn't parsed, but I can see its mention in the codebase.

I use pg-promise in my project, and I have sslmode parameter in the Postgres connection string from Google Cloud. So I can't connect due to the database "dbname?sslmode=disable" does not exist, that's why I'm asking :)

[vitaly-t]

You can, for the time being use generic connection-string to parse it, and use the connection object with any parameters that you want.

Other than that, I submitted a PR there sometime ago, but it's still just hanging there.

[charlie-wasp]

Thank you, I already found out that problem lies in fact in typeorm, not pg-promise

But I still wonder, what are reasons behind current state of affairs? Why I have to parse connection string myself beforehand?

[vitaly-t]

There's some discrepancy between this driver and what that old parser can do. It was somewhat updated lately, but the old version is still referenced here, hence the mess. At least if you parse it yourself, you can be certain of how it works :)

[charmander]

The option is called ssl, so if you want it to come from pg-connection-string, it looks like it’s ?ssl=…. (I don’t think using a different connection string parser will change that.) See the line above with { sslmode: this.ssl } when the ssl option isn’t an object.

[charmander]

This is probably an oversight in implementing PostgreSQL-connection-URI-compatible options, though, maybe related to ssl=true also existing:

For improved compatibility with JDBC connection URIs, instances of parameter ssl=true are translated into sslmode=require.

[vitaly-t]

I don’t think using a different connection string parser will change that.

What makes a difference - this driver continues to use an ancient version of pg-connection-string, and for no good reason that I know of.

And though I suggested more than once to switch over to the generic connection-string, it is turned down every time on some premise of old compatibility that few would care about. So you keep getting issues open and people getting confused about all the discrepancies going on between the object format and the connection string syntax. This should have been sorted ages ago.

[charmander]

@vitaly-t I’m not sure what “What makes a difference” means. Anyway, mixing pg options and libpq options into the same connection URI syntax is a mistake, in my opinion. Switching to “generic connection-string”, which uses (now, an unspecified superset of) the MongoDB connection string spec instead of the libpq implementation would also be a mistake.