Skip to content

Deploy: support URI-form (postgresql://) connection strings — Npgsql's key-value-only parser rejects them #261

Description

@mforce

Deployment-readiness gap (#244), BLOCKER.

Problem

Many managed-Postgres platforms expose the connection as a libpq-style
postgresql://user:pass@host:5432/db URI. Npgsql's connection-string parser
accepts only key-value form (Host=…;Username=…;Password=…;Database=…) — a
postgresql:// URI throws at data-source construction. The value flows unmodified:
GetConnectionString("Default") (Program.cs:192) → builder.UseNpgsql(connectionString) (PostgresDbContextConfigurator.cs). A repo-wide search confirms there is no URI→key-value conversion anywhere. On any host that hands us a URI, the process throws at startup before it binds a port.

This is a portable robustness fix, not tied to one provider — URI-form connection strings are the norm across managed-Postgres platforms.

Fix (app-side)

Add a small postgresql:// → NpgsqlConnectionStringBuilder shim in
PostgresDbContextConfigurator (use System.Uri + the builder, not string
hacking — prefer framework facilities): if the configured connection string
parses as a postgres/postgresql URI, translate host / port / user / password /
database (and query params such as sslmode) into key-value form before
UseNpgsql; otherwise pass it through unchanged. Which platform env-var holds the
URI is deploy-repo config, not app code.

Verify

Set ConnectionStrings__Default=postgresql://u:p@h:5432/db and boot — reproduces
the throw today; after the fix, parses and connects. Key-value strings keep working
unchanged.

Part of the #244 deployment-readiness audit; tracked in epic #15.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions