On Wednesday 15 December 2010 15:40:20 Robert Haas wrote: > 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. True. Thats a separate thing.
> >> 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. Currently there are no other locations where we errors could get thrown at that point but I see where youre going. You could use "DoingCommandRead" to solve that specific use-case, but the COMERROR ones I don't see as being replaced that easily. We could introduce something like NoLogToClientBegin(); NoLogToClientEnd(); int NoLogToClientCntr = 0; but that sounds like overdoing it for me. Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers