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

From: Fabian Knittel <fabian(dot)knittel(at)avona(dot)com>
To: Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com>
Cc: psycopg(at)postgresql(dot)org
Subject: Re: RFC: Extend psycopg2.connect to accept all valid parameters?
Date: 2011-11-16 21:38:37
Message-ID: 4EC42D5D.10609@avona.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: psycopg

Hello Daniele,

Am 16.11.2011 21:50, schrieb Daniele Varrazzo:
> You are right, env variables are less than optimal. I forgot a better
> option: if connect() is called with a single string parameter instead
> of keyword arguments you can pass any libpq parameter:
[...]
> This is definitely a better solution than the env.

Agreed. Explicitly building the dsn would be a viable solution, which
could be implemented in sqlalchemy. This is what I was aiming at in
solution c) from my initial mail. Instead of passing kwargs, sqlalchemy
would need to be changed to explicitly build the dsn string and pass
that to psycopg.

[... Snipped discussion of solution b) ...]
> I don't see anything bad against the feature. But: do we really need
> the keywords pass-through, given the fact that the connection string
> already covers all the required cases? It looks more like syntactic
> sugar, and if you have to fix a client to support a new keyword / all
> the keywords, they can be fixed by generating a connection string
> instead of forwarding the **kwargs. ... mmm... reading back the head
> of the thread, as you describe it sqlalchemy would already work using
> the **kwargs, whereas it should be patched to pass psycopg a
> connection string instead. So it's a matter of patching us (to pass
> **kwargs through) or them (to convert the url to a connection string
> instead of a doct) it seems...

Precisely. This is what I was trying to discuss. :-) (Sorry for not
clearly communicating that from the start.)

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.

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.)

Cheers
Fabian

In response to

Responses

Browse psycopg by date

  From Date Subject
Next Message Daniele Varrazzo 2011-11-16 22:23:21 Re: RFC: Extend psycopg2.connect to accept all valid parameters?
Previous Message Daniele Varrazzo 2011-11-16 20:50:25 Re: RFC: Extend psycopg2.connect to accept all valid parameters?