Re: Make java client lib accept same connection strings as psql

On Sat, Feb 22, 2020 at 4:05 AM David G. Johnston <
david(dot)g(dot)johnston(at)gmail(dot)com> wrote:

> On Fri, Feb 21, 2020 at 6:21 PM Michael Leonhard <michael(at)leonhardllc(dot)com>
> wrote:
>
>> 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.

As to your actual example, the part of syntax that is treated differently
in libpq is the the "userinfo":
https://tools.ietf.org/html/rfc3986#section-3.2.1
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(at)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