Re: RFC: Extend psycopg2.connect to accept all valid parameters?
От | Daniele Varrazzo |
---|---|
Тема | Re: RFC: Extend psycopg2.connect to accept all valid parameters? |
Дата | |
Msg-id | CA+mi_8ZRMpN7FP05ckFTDjFKnVLnZ7pa=GZ6m2Y5KqBVQmnMug@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: RFC: Extend psycopg2.connect to accept all valid parameters? (Fabian Knittel <fabian.knittel@avona.com>) |
Ответы |
Re: RFC: Extend psycopg2.connect to accept all valid parameters?
|
Список | psycopg |
On Wed, Nov 16, 2011 at 9:38 PM, Fabian Knittel <fabian.knittel@avona.com> wrote: > I'm willing to write a patch, but I first wanted to find out what kind > of patch (if any) would be acceptable in psycopg. The pass-through > solution is clearly only syntactic sugar, but as there's already some > keyword support, it would be nice to make this more generic and > therefore more intuitive. For me, transparent pass-through of the keywords arguments to a connection string would be perfectly acceptable; an exhaustive list of libpq-supported parameters not so much. > 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. -- Daniele
В списке psycopg по дате отправления: