On Wed, Dec 15, 2010 at 7:47 AM, Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
