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 <[email protected]> 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@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://[email protected]/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
