On Fri, Mar 14, 2014 at 6:50 PM, Daniele Varrazzo
<daniele.varrazzo@gmail.com> wrote:
> On Fri, Mar 14, 2014 at 6:42 PM, David Fetter <david@fetter.org> wrote:
>
> Hello,
>
>> I've heard rumors on and off over the years that this feature is on
>> its way into psycopg2. Is there any substance to them, and if so,
>> what's the current status?
>
> It's a project I'd like to work on. But not for free (as in beer). I
> estimate about 3 months of developments for which I'd like to get paid
> at professional rate.
Just because somebody has raised the question on other media, what I'm
referring here is switching psycopg to use PQexecParam from PQexec,
and as a consequence using the new adaptation infrastructure to use
PQprepare/PQexecPrepared. This would be a major rewrite and is a topic
that, on and off, has been talked about for some time. Most
comprehensive public report is
<http://www.postgresql.org/message-id/AANLkTi=ym3SCQKCQBtp8RJHUswwAPOpjXYKTXS=aHWzp@mail.gmail.com>.
Of course one can access prepared statements via sql PREPARE/EXECUTE
as illustrated in
<http://initd.org/psycopg/articles/2012/10/01/prepared-statements-psycopg/>:
this hasn't found its way in the library because there are too many
open questions about its interface and implementation: automatically
preparing cursor or extra methods? A single prepared statement per
cursor or LRU cache? Some solutions may be too manual, other may put
too much policy for a driver; I haven't received much feedback about
the topic and haven't used the feature myself enough to make my mind.
So, if you have opinions about what would be the optimal interface for
prepared statements I'm open to suggestions: an implementation based
on the current adaptation infrastructure would end up in one of the
next psycopg2 releases at the usual fee I've been working all these
years, which is zero, zilch, nada (love for the project and public
recognition have been enough). If we are thinking about the "real
params" "psycopg3" plan: I know the implementation details for it and
I know that it would take me about three months to get it right (and
I'm one of these "please multiply by 2 everything I say" optimistic
developers). Other features I've developed (such as the async support)
were for my employer's benefit too and I could work on them at office
time as well as on my free time, but this is not a feature my company
needs now so I think it's just fair not pushing the cost of
development on my employer.
Of course I'm not closing the door to anybody else who wanted to
contribute to the development of the requested features: there has
simply never been so much external contribution and my default mindset
is that I have to write features, docs, tests myself. If there is any
company that would like to sponsor the new development I can be
reached for further discussion.
I think the community has largely benefited from the work I've put in
the project for free across several years, and I think it's only fair
if I don't want to work /gratis/ for months on something I don't need
personally and instead prefer to follow other pursuits with my not
copious spare time.
-- Daniele
