| From: | Federico Di Gregorio <fog(at)dndg(dot)it> |
|---|---|
| To: | Marko Kreen <markokr(at)gmail(dot)com> |
| Cc: | psycopg(at)postgresql(dot)org |
| Subject: | Re: libpq custom row processing |
| Date: | 2012-08-07 13:25:38 |
| Message-ID: | 50211752.7010204@dndg.it |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | psycopg |
On 07/08/12 15:14, Marko Kreen wrote:
> My point is that the behavior is not something completely new,
> that no-one has seen before.
>
> But it's different indeed from libpq default, so it's not something
> psycopg can convert to using unconditionally. But as optional feature
> it should be quite useful.
I agree. As an opt-in feature would be quite useful for large datasets
but then, named cursors already cover that ground. Not that I am against
it, just I'd like to see why:
curs = conn.cursor(row_by_row=True)
would be better than:
curs = conn.cursor("row_by_row")
Is row by row faster than fetching from a named cursor? Does it add less
overhead. If that's the case then would be nice to have it as a feature
for optimizing queries returning large datasets.
federico
--
Federico Di Gregorio federico(dot)digregorio(at)dndg(dot)it
Studio Associato Di Nunzio e Di Gregorio http://dndg.it
And anyone who yells "fork" deserves to get one stuck in them.
-- Dan Winship
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Magnus Hagander | 2012-08-07 13:34:57 | Re: libpq custom row processing |
| Previous Message | Marko Kreen | 2012-08-07 13:14:37 | Re: libpq custom row processing |