Re: Inconsistency in libpq connection parameters, and extension thereof

On Fri, Jun 8, 2012 at 7:53 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> On Fri, Jun 8, 2012 at 1:48 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Wed, Jun 6, 2012 at 6:04 PM, Daniel Farina <daniel(at)heroku(dot)com> wrote:
>>> On Wed, Jun 6, 2012 at 1:13 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>>> On Wed, Jun 6, 2012 at 4:08 PM, Magnus Hagander <magnus(at)hagander(dot)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?
>
> I think we *have* to make the change for regular parameters, for
> security reasons.
>
> What we do with "prefixed parameters" can be debated... But we'll have
> to pass those to the server anyway for validation, so it might be an
> uninteresting case.

OK, committed.

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