On Fri, Dec 9, 2011 at 3:03 AM, Alexander Shulgin <a...@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 new syntax (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 recognized by 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
