How about making the Java client library accept the same connection
strings as psql and other command-line tools? [...]
That falls outside the scope of this list/project. The separate pgJDBC project team would need to decide to take that up.
Michael,
While your proposed end goal sounds as a desirable thing to me, there are certain obstacles to that, unfortunately.
First, consider that the URL support appeared in libpq after, not before the support in JDBC driver.
Second, the common subset of allowed connection parameters between the two is only as big as "host", "port", "database", "user" and "password".
Additionally, libpq understands the "ssl=true" parameter for JDBC compatibility, though I don't think that was a good idea in the end. For one, in the JDBC world "ssl=false" is treated exactly the same as "ssl=true" or any other value, which is questionable design in the first place. And even if you could use exactly the same URL in both libpq-based and JDBC clients, without running into syntax errors, the semantics of "ssl=true" is subtly different between the two: in the former case, the client does not attempt to validate certificate, nor the hostname, as opposed to the latter.
The JDBC driver could be extended to support this as well, as such a change is backwards-compatible. As David has pointed out, this question should be asked to the PgJDBC project.
Lastly, the RFC provides some good arguments as to why providing username and, especially, password in the connection URL is undesirable. While the "user:password@host" or "?user=fred&password=secret" syntax can be handy for local testing, this is definitely not something that should be used in production. Both libpq and the JDBC driver provide ways to pass login credentials in a more secure manner.
Kind regards,
--
Alex
