Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.500.181\))
Subject: Re: Feature: Use DNS SRV records for connecting
From: Andrey Borodin <x4mmm@yandex-team.ru>
In-Reply-To: <8398C22D-429A-4980-9028-4F941F2B7483@yandex-team.ru>
Date: Tue, 12 May 2026 14:46:38 +0500
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
 Feike Steenbergen <feikesteenbergen@gmail.com>,
 PostgreSQL mailing lists <pgsql-hackers@postgresql.org>,
 Andres Freund <andres@anarazel.de>
Content-Transfer-Encoding: quoted-printable
Message-Id: <0682441F-1AB2-434C-B785-741EEC614FF0@yandex-team.ru>
References: 
 <CAK_s-G2_3S09_EA+nRxxefMW+0-UwKE=Uj6bCdBpPncPVRpM_g@mail.gmail.com>
 <7386.1565707387@sss.pgh.pa.us>
 <20190814180143.62533ohqlaqcl7so@alap3.anarazel.de>
 <8398C22D-429A-4980-9028-4F941F2B7483@yandex-team.ru>
To: Jacob Champion <jacob.champion@enterprisedb.com>
Archived-At: 
 <https://www.postgresql.org/message-id/0682441F-1AB2-434C-B785-741EEC614FF0%40yandex-team.ru>
Precedence: bulk

Hi hackers!

> On 22 Apr 2026, at 14:48, Andrey Borodin <x4mmm@yandex-team.ru> wrote:
>=20
> 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@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 =C2=A73.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=3D keyword
   parameter. Smallest API surface, no compatibility concerns for
   any driver. No URI form to use DNS SRV at all.

     srvhost=3Dcluster.example.com dbname=3Dmydb =
target_session_attrs=3Dread-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@cluster.example.com/mydb?target_session_attrs=3Dread=
-write
     postgres+srv://user@cluster.example.com/mydb

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

     =
pgsrv://user@cluster.example.com/mydb?target_session_attrs=3Dread-write

My slight preference is (1). The srvhost=3D 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
=C2=A77.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 =E2=80=94 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=