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

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:
>> > On Wed, Nov 16, 2011 at 9:38 PM, Fabian Knittel
>> > <fabian(dot)knittel(at)avona(dot)com> wrote:
>>> >> Instead of implementing the kwargs-pass-through approach in C, I could
>>> >> also imagine a solution where psycopg2._psycopg.connect (psyco_connect)
>>> >> is changed to only support a single string-DSN-parameter.
>>> >> psycopg2.connect would be a pure-Python method that wraps around
>>> >> psycopg2._psycopg.connect and provides the kwargs to dsn conversion
>>> >> sugar. (This would move all the icky string manipulation stuff from C
>>> >> to Python.)
>> >
>> > Yes, I agree: this is a less scary implementation if you wanted to
>> > provide a patch. I'd either leave psycopg2._psycopg.connect as it is,
>> > with the currently supported keyword arguments, or rename it to
>> > psycopg2._psycopg._connect, supporting only the connection string.
>> > Either way, the function would be imported in the module as _connect,
>> > to be invoked by a connect() function written in python and
>> > responsible to build the connection string.
> 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). So it needs some manual testing, or a strategy for
> automatic ones, definitely more than the 10 minutes I've tried before
> pushing.
>
> I'd like to hear from somebody else (mostly Fog, but anybody else)
> before having it merged and released: tests and feedbacks are welcome.

Looks good but I have a question: does automatic conversion always
generates a valid connection string? Do we need quoting for some of the
parameters? The main idea behind .connect() was to use dsn for the
generic case and provider keyword arguments as a utility for the most
common cases while the patch actually says "it's ok to use kwargs for
everything" and if we do that then it should work out of the box.

But I almost always use username+password only so I don't know if some
parameters need special treatment.

federico

--
Federico Di Gregorio fog(at)initd(dot)org
La macchina virtuale elabora quindi dati adempiendo le sue funzioni
specifiche senza esistere nella realtà degli oggetti. -- uno studente