fix: PgConnectOptions docs#3809
Conversation
f430a00 to
8c4b663
Compare
|
I'm going to merge this so you get the attribution, but the release is going to have pretty significant wording changes since this could be blended better with the rest of the doc comment. |
|
As it turns out, the handling of I'm not sure whether to fix that or leave it as-is. |
* chore: prepare 0.8.4 release * fix(postgres): send `limit: 0` for all `Execute` messages fixes #3673 * fix: let `CertificateInput::from` infer any PEM-encoded document #3809 (comment) * doc: improve documentation of `PgConnectOptions` fixes #3740 * chore: update CHANGELOG from PR
If inlining key materials via the environment is a deliberate feature and not just a feature by accident than IMO: I think the internal representation of certs and keys has to be split to fix this. And IMO it should be fixed. We need dedicated types so we can run dedicated inference logic. Basically we'd need to add an On the other hand if its not a deliberate feature and just a feature by accident: Inference logic should NOT exist and the I personally prefer that |
From PostgreSQL's docs it seems that all these options only accept the param as filepath. Also the documented "system" option doesn't seem to be handled in sqlx-postgres. |
Note I'm PRing this to document the current behavior, I'm not sure if it was the intention of the original author to support MORE behavior than
libpqoffers.If I look at
pub fn ssl_client_key(self, key: impl AsRef<Path>) -> PgConnectOptionsthere is no way to "set" the inline version ofCertificateInput, it only accepts the file version. This potentially should be lifted for symmetry with the environment variables.This may not be the intention? But also I seen no reason to artificially constrain
sqlx-postgresto libpq behavior, in lots of scenarios (single file lambda binary) its much better to be able to set the certificate inline.Regardless of what the desired final behavior is: This PR just documents the status quo, even if we wish to change it in the future.
Is this a breaking change?
no