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 11:46:10 |
Message-ID: | 50210002.8060100@dndg.it |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | psycopg |
On 07/08/12 13:41, Marko Kreen wrote:
> Same thing happens when you fetch the result in transaction
> and later query fails with error thus invalidating earlier
> processing. So nothing new.
>
> Or how about FETCH 100 from cursor in transaction,
> and first few succeed and later one fails.
>
> It's up to user code to handle such cases correctly
> and "correct" here depends on actual business logic
> of the transaction.
>
> The warning is there because there is now new
> failure scenario, but not because the failure
> needs any kind of special handling.
I don't agree. Simple code like:
curs.execute("SELECT * FROM xs")
for x in curs.fetchall():
# do something like writing to the file system with x
will have a different effect if row-by-row processing is enabled. Before
nothing would be changed on the file system in case of error: the
fetchall() is "atomic"; while now you write to the file system until the
row that causes the error is processed.
federico
--
Federico Di Gregorio federico(dot)digregorio(at)dndg(dot)it
Studio Associato Di Nunzio e Di Gregorio http://dndg.it
There's no greys, only white that's got grubby. I'm surprised you
don't know that. And sin, young man, is when you treat people as
things. Including yourself. -- Granny Weatherwax
From | Date | Subject | |
---|---|---|---|
Next Message | Marko Kreen | 2012-08-07 13:14:37 | Re: libpq custom row processing |
Previous Message | Marko Kreen | 2012-08-07 11:41:41 | Re: libpq custom row processing |