Re: Feature: Use DNS SRV records for connecting

From: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
To: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Feike Steenbergen <feikesteenbergen(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>
Subject: Re: Feature: Use DNS SRV records for connecting
Date: 2026-05-12 09:46:38
Message-ID: 0682441F-1AB2-434C-B785-741EEC614FF0@yandex-team.ru
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi hackers!

> On 22 Apr 2026, at 14:48, Andrey Borodin <x4mmm(at)yandex-team(dot)ru> wrote:
>
> I'm proposing this across the PostgreSQL driver ecosystem

While preparing equivalent patches for pgx, pgjdbc and npgsql, Jack
Christensen (pgx maintainer) raised a concern [0] about the
postgres+srv:// URI scheme I proposed here.

The issue is specific to Go's net/url package [1]. In Go 1.26 the URL
parser was tightened and broke parsing of HA connection strings of
the form postgresql://user(at)h1:1,h2:2/db (colons inside the authority
after a comma). The Go team addressed this by relaxing validation,
but only for the "postgres" and "postgresql" schemes - any new
scheme, including "postgres+srv", gets the strict modern parser. For
a single SRV name in the authority this is probably fine in practice,
but Jack reasonably points out that deviating from postgresql:// is
a compatibility bet without much upside. [2]

Per RFC 3986 §3.1 the "+" in a scheme name is syntactically legal.
Per RFC 7595 / BCP 35, schemes can be registered with IANA, but
neither "postgresql" nor "mongodb+srv" is in the IANA registry today,
so there is no formal gate to pass - just our own consensus on what
to ship.

On a related note, "mongodb", "redis" and "rediss" (Redis over TLS) are
both registered with IANA as provisional schemes, while "mongodb+srv" is
not - so there is no consistent precedent either way.

Given the above, I see three options:

1. Drop the +srv URI scheme entirely. Keep only the srvhost= keyword
parameter. Smallest API surface, no compatibility concerns for
any driver. No URI form to use DNS SRV at all.

srvhost=cluster.example.com dbname=mydb target_session_attrs=read-write

2. Keep postgresql+srv:// / postgres+srv:// as proposed. Aligns with
the mongodb+srv:// precedent and reads naturally; a single cluster
name in the authority is unaffected by Go's stricter parser, but
driver authors take on a small risk for any future tightening.

postgresql+srv://user(at)cluster(dot)example(dot)com/mydb?target_session_attrs=read-write
postgres+srv://user(at)cluster(dot)example(dot)com/mydb

3. Some other shorthand (pgsrv://). Avoids "+" entirely but invents
yet another name with no clear advantage.

pgsrv://user(at)cluster(dot)example(dot)com/mydb?target_session_attrs=read-write

My slight preference is (1). The srvhost= parameter alone expresses
intent unambiguously and avoids opening a second scheme namespace
that every driver in the ecosystem would need to replicate.

If we go with option (2), registering "postgresql+srv" as a
provisional scheme with IANA (First Come First Served per RFC 7595
§7.1) would take minimal effort and give the scheme a stable
reference. Interestingly, even "postgresql" itself is not in the
IANA registry despite being in use for over 20 years, so registration
is not a prerequisite — but it would be a nice step toward treating
SRV as a first-class URI scheme on par with mongodb+srv.

On the other note "redis" and "rediss" are both provisioned with IANA.

WDYT?

Best regards,
Andrey Borodin.

[0] https://github.com/jackc/pgx/pull/2538
[1] https://github.com/golang/go/issues/75859
[2] https://github.com/jackc/pgx/issues/2404

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Yugo Nagata 2026-05-12 09:47:21 Re: Track skipped tables during autovacuum and autoanalyze
Previous Message shveta malik 2026-05-12 09:26:25 Re: Proposal: Conflict log history table for Logical Replication