Add pg connection options creation without environment

[mbj]

Is this a breaking change?

no.

Rationale:

I make SQL tools that need to behave correctly in situations the environment cannot be relied upon (developer boxes, my code is run as a 3rd party library etc) and where my SQL connections need to be precisely controlled by my own code.

Before my only option was to use new_without_pgpass and explicitly unset any field that may have been picked up by that function in my own code. But this is breaky as sqlx-postgresql may accumulate new fields in new releases. Also not all fields have APIs to unset the effect of env reflection.

[abonander]

I'm amenable to this change, but I have some nits.

This also makes me wonder if we should completely rethink how configuring the connection works. We defaulted to "just do whatever libpq does", but it seems to me like that should be a conscious decision given to the application developer.

It seems a lot of users don't care or generally don't want to "just do whatever libpq does" and are perfectly happy configuring everything explicitly. So maybe that should be the default mode of operation here and maybe "do what libpq does" should be explicitly opt-in.

Breaking changes to behavior are incredibly difficult to effectively warn the user about though, especially if they don't come alongside breaking API changes.

[abonander]

port and ssl_mode have reasonable defaults: 5432 and Prefer, respectively.

host could arguably default to localhost or the standard Unix socket path for the platform; we already have that logic implemented in this file.

username is the hardest to choose a reasonable default for. Defaulting to the OS username doesn't really make sense to me anymore since that assumes the application is running on the same system as the database, which I don't expect is all that common these days; we only default to it because that's what libpq does. I would say postgres since that's generally the username that the Postgres server is installed under.

[mbj]

I mostly did a mechanical transformation of the existing new_without_pgpass function. Very happy to go beyond that.

Yeah happy to add a default port.

But I think we should reconsider on ssl_mode, if SSL is supported by the server it behaves like require which verifies nothing. Having users explicitly think about ssl_mode may be the best option.

Alternatively we go for: 2 functions: new which would default to ssl_mode = Disable and new_ssl with ssl_mode = verify-full both documented.

This way we can steer users to the most appropriate defaults and make them explicitly think about what the needs of their environment and its reuqirement is. I'd love to do my part to avoid having to flag (and demo, and report) the MITM-ability of ssl_mode = require.

[mbj]

It seems a lot of users don't care or generally don't want to "just do whatever libpq does" and are perfectly happy configuring everything explicitly. So maybe that should be the default mode of operation here and maybe "do what libpq does" should be explicitly opt-in.

Yes I agree to that. Want me to re-PR this replacing new as a breaking change, adding new_with_libpq_behavior?