Re: Feature: Use DNS SRV records for connecting

Hello!

I'm speaking only on the design questions here; I have not looked at
the patch implementation yet.

On Tue, May 12, 2026 at 2:47 AM Andrey Borodin <x4mmm(at)yandex-team(dot)ru> wrote:
> 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]

So this doesn't answer your broader question, really, but I consider
it a Very Good Thing that Go is enforcing stricter validation. If we
choose to introduce a brand-new scheme, I think we should do it by the
book and not carry over our oddities from 2012.

> 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.

As a continuation of the above, I think it'd be good to ask for IETF
review on any new scheme. The [scheme]+[variant]: form has some
uptake, but there are also expert reviewer notes saying that some
attempts might make things difficult for implementers (or others in
the ecosystem).

> 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.

Either way, we'll need to define the semantics of mixing this new mode
with the existing parameters. I think that's likely to introduce its
own subtle compatibility concerns if we don't design it up front.

(Your proposal doesn't introduce this problem, but we never should
have allowed query parameters to modify the prior components --
scheme, authority, path -- of the URI. I am strongly motivated to fix
that, though I don't really want to derail SRV conversations too much
with it.)

> 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.

Can you elaborate on the additional risk?

IMO, if a URI identifies a single resource (the cluster), it doesn't
seem like anyone needs to support our comma pseudo-syntax anymore.
Drivers that want to connect to multiple clusters can take multiple
fully formed URIs, and define how to configure that in a way that
makes sense for them.

> 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

I guess I don't see what this accomplishes. The `+` is not the problem, right?

--

I would additionally propose options 4 and 5 (which you don't need to
feel obligated to give any thought to):

4. Use the new behavior opportunistically somehow, similar to how
https: has continued to evolve the underlying protocol and DNS lookup
without any scheme changes at all. Whether this is technically
feasible without usability and security concerns... I don't know at
this point.

5. Moonshot: break compatibility outright, and design a scheme that
does exactly what we want in 2026. Strong URI semantics, enforcement
of TLS, useful DNS semantics, etc., etc. Represents complete
derailment of the thread. :)

Thanks,
--Jacob