Re: using server side cursor
От | Daniele Varrazzo |
---|---|
Тема | Re: using server side cursor |
Дата | |
Msg-id | CA+mi_8a8jO=6sodHeifPv1+n_5Gd_oLSS+H0-q=Yd7gng49_WQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: using server side cursor (thomas veymont <thomas.veymont@gmail.com>) |
Ответы |
Re: using server side cursor
Re: using server side cursor |
Список | psycopg |
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
В списке psycopg по дате отправления: