Re: Notes on implementing URI syntax for libpq

Excerpts from Daniel Farina's message of Mon Dec 05 11:56:19 +0200 2011:
>
> I think the current direction is fine, although as Robert Haas has
> said, I am not really at all inclined to view JDBC compatibility as
> any kind of a plus. JDBC URLs are weird, and do the drivers actually
> link libpq anyway? That world is unto itself.

Daniel,

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 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 new syntax (also, eventually.)

> Are there any provisions for choosing X.509/cert authentication? I
> imagine not, but out-of-band presentation of that information is the
> norm there, and I'm not sure if is any room for improvement within
> reach.

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.

> >> If we can decide on this, we should also put reasonable effort into making JDBC support the same syntax.
> >
> > What would be our plan on this?  Since the syntax proposed here is strictly a superset of the existing JDBC syntax, I would think this qualifies as an improvement and it would be backwards compatible with any previous version of the JDBC connector.
>
> I suppose that is nice, but is this designed, or coincidental? Is
> there any fundamental reason why the JDBC driver will remain so
> similar to libpq in the future? Will people realistically be able to
> use one URL across their Java and libpq projects in most situations,
> now and in the forseeable future, including the keyword options?
> Because as soon as one encounters the need to maintain two URLs for
> any reason, the otherwise real convenience regresses into bloat.

See above. The hope is that URIs will be compatible sans the driver-specific extra query parameters which might be not recognized by either party.

--
Regards,
Alex