Re: [PATCH] V3: Idle in transaction cancellation

On Wed, Dec 15, 2010 at 7:47 AM, Andres Freund <andres@anarazel.de> wrote:
> I thought about doing that first. Btw, LOG_NO_CLIENT is just a more abstracted
> way of what COMERROR did before...

Hmm, but it must not be quite the same, because that didn't require
the silent_error_while_idle flag.

>> Yeah.  I'll try to find some time to think about this some more.  It
>> would sure be nice if we could find a solution that's a bit
>> conceptually cleaner, even if it basically works the same way as what
>> you've done here.
> I would like that as well. I am not sure you can achieve that in a reasonable
> amount of work. At least I couldn't.

Is there a way that errstart() and/or errfinish() can know enough
about the state of the communication with the frontend to decide
whether to suppress edata->output_to_client?  In other words, instead
of explicitly passing in a flag that says whether to inform the
client, it would be better for the error-reporting machinery to
intrinsically know whether it's right to send_message_to_frontend().
Otherwise, an error thrown from an unexpected location might not have
the flag set correctly.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company