On Fri, Oct 14, 2011 at 2:22 PM, thomas veymont
<thomas.veymont@gmail.com> wrote:
> thanks for your helpful answers.
>
>>> mycursor.execute ( "fetch mycursor" )
> is working okay.
>
> you are right : using the psycopg native support for cursors makes
> clearer code. But, yes indeed, the pgsql function is somewhat a
> mandatory API to the database, so the Python code doesn't have to know
> the inner query structure.
>
> Daniele, beside the hack you are providing, you say : "all cursors
> from the same connections live in the same transaction"
> => is it something specific that is true today but may change in the
> future ? I mean, may I rely on this for a long-living code ?
It's a fundamental psycopg design choice, It's not going to change.
The thing that is relatively brittle and makes of my idea an hack is
that the named cursor is used "uninitialized": if you try calling
fetch*() on a regular (not named) cursor without calling execute()
before, it will laugh at you. But I acknowledge the need of using a DB
API provided via a cursor (honestly not the most common scenario, in
many years I can't remember it being requested). We could either
design a feature just for that, or add proper tests to the test suite
and guarantee for the future that you will be able to use a named
cursor regardless of where the refcursor is coming from (still limited
to cursors on the same connection of course). At this point we will
document the hack which will officially become a supported feature :)
Thoughts?
-- Daniele