Summary

PgGraph::connect() and PgGraph::connect_config() (src/graph/pg.rs, confirmed in both 0.9.2 and 0.10.0) hardcode postgres::NoTls:

pub fn connect(url: &str) -> Result<Self> {
    ...
}

pub fn connect_config(config: &Config) -> Result<Self> {
    let mut client = config.connect(NoTls).map_err(pg_err)?;
    ...
}

There is no way to pass a TLS connector (e.g. postgres-native-tls or postgres-rustls/tokio-postgres-rustls) through the public API. This forces any consumer connecting to a Postgres server that requires TLS (sslmode=require or stricter) to fail with:

Error { kind: Tls, cause: Some(NoTlsError(())) }

Reproduction

• Postgres/RDS server with sslmode=require (or a parameter group enforcing SSL negotiation).
• Call PgGraph::connect("postgresql://user:pass@host:5432/db?sslmode=require").
• Connection fails immediately with the TLS/NoTlsError above, even though the same DSN works fine through sqlx (tls-rustls-ring feature) in the same process.

Impact

Consumers that want defense-in-depth encryption on internal DB traffic (e.g. same-VPC EC2→RDS, which is our case) cannot use the graph-pg feature at all without disabling TLS on the server side — which isn't acceptable for a regulated (FSS) production environment. We currently have to fall back to sslmode=disable just for the graph connection while keeping TLS for the main data pool, which is an inconsistent security posture.

Suggested fix

Accept a TLS connector in the public API, e.g.:

• PgGraph::connect_tls(url: &str, connector: impl MakeTlsConnect<Socket> + ...), or
• Have connect/connect_config inspect the DSN's sslmode and use postgres-rustls/native-tls automatically when TLS is requested (mirroring how sqlx's tls-rustls-ring feature already handles this transparently), gated behind a new Cargo feature (e.g. graph-pg-tls) to avoid pulling in TLS deps for consumers who don't need it.

Happy to test against a real RDS instance (sslmode=require, rds.force_ssl param) once a fix lands.