Re: Notes on implementing URI syntax for libpq - Mailing list pgsql-hackers

On Fri, Dec 9, 2011 at 3:03 AM, Alexander Shulgin <ash@commandprompt.com> wrote:
> The JDBC driver is special in that it intentionally does not use libpq.  Given every other binding (think Ruby,
Python,Perl, Tcl, etc.) does use libpq, it makes perfect sense to me to make the syntax compatible with JDBC. 

I am with you until the reasoning of the last part, which is can be
(as I understand it) rephrased to "every other major language
ecosystem uses libpq, so therefore it makes perfect sense to have the
syntax compatible with JDBC."  To which I say, "what?"

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"

> I see this as a two-fold effort: add URI syntax to libpq *and* improve JDBC's syntax to support the usual "user:pw@"
notation. This way, not only the above language's bindings URI syntaxes would become compatible with each other
(eventually,with release of new libpq and new drivers' versions,) but they would also be interchangeable with JDBC's
newsyntax (also, eventually.) 

Okay. This is how I teased out my interpretation above.

> Since the idea is to parse any supported URI query parameters, this is likely going to Just Work(tm) if you add
proper"sslcert=&sslkey=" query parameters to the connection URI. 

Hmm. I guess the only downside is one has to have files materialized
to make that work, and one cannot really embed them in the URL (for
files that long, it is madness anyway).  But I do appreciate the exact
symmetry with the libpq options.

> The hope is that URIs will be compatible sans the driver-specific extra query parameters which might be not
recognizedby either party. 

How about a more general quirk of the hypothetical URL parsing code:
because JDBC's URLs are not URLs (schemes cannot have colons, per
rfc1738, section 2.1) treat the JDBC string specially and ignore it,
and parse the rest as a legitimate URL.  One could be even more
permissive and state that all tokens before the last colon-delimited
part of the scheme are ignored:

i:am:feeling:like:postgresql://(etc)
jdbc:postgresql://(etc)
psycopg2:postgresql://(etc)

Which would reduce to the same thing as:

postgresql://(etc)

What I can't get excited about is:

postgresql:ssl://user:pw@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.

--
fdr