Re: Notes on implementing URI syntax for libpq

Excerpts from Daniel Farina's message of Fri Dec 09 23:04:26 +0200 2011:
>
> I guess if I move the parenthetical grouping of logic around, what you
> are probably intending to say is "everyone except this one ecosystem
> does the normal thing, so we have an opportunity to Unite The Clans,
> by absorbing a unique aspect of one of them"

Yes, what I meant is something more or less like that.

> i:am:feeling:like:postgresql://(etc)
> jdbc:postgresql://(etc)
> psycopg2:postgresql://(etc)
>
> Which would reduce to the same thing as:
>
> postgresql://(etc)

Well, it wasn't suggested that JDBC people paste their URIs to psql, while keeping the "jdbc:" prefix, that would be really weird thing to do.

However, I have just noticed they *do* require that part themselves, like in:

String url = "jdbc:postgresql://localhost/test";
Connection conn = DriverManager.getConnection(url);

It is really weird, since as far as I can see from the docs, the "jdbc:" part is always discarded by the driver manager. That must be some true Java way of doing things. :-p

> What I can't get excited about is:
>
> postgresql:ssl://user:pw(at)host:port/dbname?sslmode=...
>
> Since this is not actually a URL, and the "scheme" using the above
> rule would be "ssl". If you really want to have SSL be part of the
> scheme (given ssl=require exists, I'd prefer One Way that involves no
> scheme alterations to denote the transport), then you can use an
> RFC-compatible notation like "+":
>
> postgresql+ssl://....
>
> For which the "scheme" would be "postgresql+ssl". Again, I'm not
> terribly excited about having a scheme that denotes the transport (in
> spite of it being semi-commonly done as in svn+ssh), especially if
> redundant with query string options.

Yeah, I was also considering "+ssl", but don't recall if I ever suggested that on the list.

My primary motivation behind making SSL stand out in the URI is that it "feels wrong" when that is pushed to the query parameters. In a real-world URI that would be impossible, since it's the server which is supposed to parse the parameters, not the client, but that can only happen after the connection has been established.

However, since we're parsing all of the "query parameters" locally in a client, this becomes less of a problem, so I would agree that we don't need a special scheme for SSL connections. Especially, since the default SSL mode is "prefer" and to override that you still need to add a "sslmode=" query parameter.

--
Alex