Re: RFC: Extend psycopg2.connect to accept all valid parameters?

From: Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com>
To: Jan Urbański <wulczer(at)wulczer(dot)org>
Cc: Fabian Knittel <fabian(dot)knittel(at)avona(dot)com>, psycopg(at)postgresql(dot)org
Subject: Re: RFC: Extend psycopg2.connect to accept all valid parameters?
Date: 2011-11-17 09:40:22
Message-ID: CA+mi_8aAEPSo9KU79HNoBTXm0QToceGr4ySQQDvmctfahU-C=w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: psycopg

On Thu, Nov 17, 2011 at 7:48 AM, Jan Urbański <wulczer(at)wulczer(dot)org> wrote:
> On 17/11/11 03:02, Daniele Varrazzo wrote:
>>
>> On Wed, Nov 16, 2011 at 10:23 PM, Daniele Varrazzo
>> <daniele(dot)varrazzo(at)gmail(dot)com>  wrote:
>> I've implemented what discussed here and pushed in a separate branch:
>>
>> https://github.com/dvarrazzo/psycopg/commit/d2b67364fd2b0b192342281d24a7e3d0a4909980
>>
>> It's open for discussion. It is not as tested as the rest of the
>> library, as there aren't many tests covering connect() in all the
>> possible ways (as there should be as many databases on the other side
>> to reply).
>
> I think the correct solution would be to document the 'dsn' parameter to
> psycopg2.connect and perhaps even encourage people using it.
>
> This pushes the trouble of parsing out and interpreting parameters to libpq,
> which is good, for in the end the important thing is that libpq sees what
> you want it to see.
>
> For instance, this patch (and AFAICS vanilla psycopg2 too) does not handle
> usernames with spaces in them.

I told the use of keyword arguments is just syntactic sugar. Which it
is known to cause cancer to the semicolon :)

Jokes aside, yes, I'd say it is a bug in psycopg since day zero. I'd
fix it regardless of the need or not to support generic keywords. Even
though fixing it in python is way easier than fixing in c, so
eventually the fix would lead to a patch very similar to the above
one.

> Instead of implementing quoting as expected
> by libpq, why not just let the user use a DSN that will work equally with
> psql as with any other libpq app out there?

The use of the dsn is documented, users can already use it. I don't
feel like pushing the users really to use either one or the other
parameters style if they both suit, but if you want to suggest
improvement to the documentation, they are welcome.

> As for SQLAlchemy, you can use the connect_args argument to pass a DSN to
> create_engine thusly:
>
> e = create_engine('postgresql://', connect_args={'dsn': 'user=foo
> sslrootcert=root.crt'})

Yes, but these arguments are passed as keywords, not as connection
string. And rightly so I'd say, otherwise it would be their problem to
escape the values building the dsn, and different drivers may have
different escaping rules, making the problem more complex for them. So
having psycopg pass them through correctly escaped as described in
<http://www.postgresql.org/docs/9.1/static/libpq-connect.html#LIBPQ-PQCONNECTDBPARAMS>
looks a good thing.

-- Daniele

In response to

Browse psycopg by date

  From Date Subject
Next Message Daniele Varrazzo 2011-11-17 09:49:06 Re: RFC: Extend psycopg2.connect to accept all valid parameters?
Previous Message Federico Di Gregorio 2011-11-17 08:31:46 Re: RFC: Extend psycopg2.connect to accept all valid parameters?