On 14/10/11 15:44, Daniele Varrazzo wrote:
> 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 :)
We can add a new parameter (existing=True?) to cursor(); to be used only
when the cursor already exists with the following behaviour:
1) execute() calls now result in an exception; and
2) you're guaranteed that fetchXXX() will wok as expected.
If you *don't* pass existing=True trying to fetch from a named cursor
without first calling execute() can result in an exception too. But
maybe this is too much...
federico
--
Federico Di Gregorio fog@initd.org
But not all bugs are an interesting challenge. Some are just a total
waste of my time, which usually is much more valuable than the time of
the submitter. -- Md