Re: Inconsistency in libpq connection parameters, and extension thereof - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Inconsistency in libpq connection parameters, and extension thereof
Date
Msg-id CA+TgmoYKsDEGOMGTb7dzqnq3DaU6Mk5oi3GON2zmdqZV-s=C-A@mail.gmail.com
Whole thread Raw
In response to Re: Inconsistency in libpq connection parameters, and extension thereof  (Daniel Farina <daniel@heroku.com>)
Responses Re: Inconsistency in libpq connection parameters, and extension thereof
List pgsql-hackers
On Wed, Jun 6, 2012 at 6:04 PM, Daniel Farina <daniel@heroku.com> wrote:
> On Wed, Jun 6, 2012 at 1:13 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Wed, Jun 6, 2012 at 4:08 PM, Magnus Hagander <magnus@hagander.net> wrote:
>>> However, not throwing errors on the URL syntax should be considered a
>>> bug, I think.
>>
>> +1.
>
> +1
>
> Here's a patch that just makes the thing an error.  Of course we could
> revert it if it makes the URI feature otherwise unusable...but I don't
> see a huge and terrible blocker ATM.  A major question mark for me any
> extra stuff in JDBC URLs.

It looks like the answer is "yes".

http://jdbc.postgresql.org/documentation/head/connect.html#connection-parameters

...but I'm inclined to think we should make this change anyway.  If
JDBC used libpq, then it might be nice to let JDBC parse out bits of
the URL and then pass the whole thing, unmodified, through to libpq,
without having libpq spit up.  But it doesn't.  And even if someone
were inclined to try to do something of that type, the warnings we're
omitting now would presumably discourage them.

Thoughts?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Skip checkpoint on promoting from streaming replication
Next
From: Magnus Hagander
Date:
Subject: Re: Inconsistency in libpq connection parameters, and extension thereof