Re: libpq custom row processing

On Tue, Aug 7, 2012 at 2:15 PM, Federico Di Gregorio <fog(at)dndg(dot)it> wrote:
> On 07/08/12 12:51, Marko Kreen wrote:
>> The callback API has been rolled back and final 9.2 will have
>> single-row-mode instead:
>>
>> http://www.postgresql.org/docs/devel/static/libpq-single-row-mode.html
>>
>> Callback API was hard to use and did not support iterative
>> result processing. This API should fix both problems.
>
> Interesting, but this is quite intimidating:
>
> While processing a query, the server may return some rows and then
> encounter an error, causing the query to be aborted. Ordinarily, libpq
> discards any such rows and reports only the error. But in single-row
> mode, those rows will have already been returned to the application.
> Hence, the application will see some PGRES_SINGLE_TUPLE PGresult objects
> followed by a PGRES_FATAL_ERROR object. For proper transactional
> behavior, the application must be designed to discard or undo whatever
> has been done with the previously-processed rows, if the query
> ultimately fails.
>
> Making sure old code continues to work and doesn't process the initial
> tuples before an exception is throw will be challenging.

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.

--
marko