Entering the discussion because this is a huge pain for me in my daily work as well.
This is not a reply to any specific post in this thread, but my first message in the thread. I see a great value in providing both a GUC and a new RAISE syntax. The different benefits of the two are maybe obvious, but perhaps worth pointing out: GUC: Good because you don't have to change any existing code. RAISE syntax: Good because you can control exactly what message should be emitted or not be emitted at that line of code. I think preserving backwards compatibility is very important. Not changing the default is not a problem for me, as long as it can be overridden. Whatever the default behaviour is, I think the need expressed by all users in this thread boils down to any of these two sentences: "I want CONTEXT to be (DISPLAYED|SUPPRESSED) for (ALL|ONLY THIS LINE) RAISE (NOTICE|WARNING|ERROR)" OR "I don't want to change the default current behaviour of CONTEXT" So we basically need a boolean setting value, where: NULL means the default behaviour TRUE means DISPLAY CONTEXT FALSE means SUPPRESS CONTEXT And the (ALL|ONLY THIS) part translates into using, * a GUC to change behaviour for ALL lines of code, * or using the RAISE syntax to change the behaviour of ONLY THIS line of code. And then we have the different message levels, for which CONTEXT is sometimes desirable in some situations: * The RAISE syntax allows controlling any message level in a natural way, as the message level is part of the syntax. * Allowing the same control using GUC would mean the message level would need to be part of the GUC key name, which means either add multiple GUCs, one for each message level, or only allow controlling the most important one and ignore the possibly need to control the other message levels. If it would be possible to somehow combine multiple message levels in the same GUC, that would solve the latter problem. We already have comma separated values for many GUCs, so maybe we could use that approach here as well. It looks like adding these two GUCs would meet the demands of all users: suppress_context_messages (enum) display_context_messages (enum) This would allow doing something crazy as: suppress_context_messages = warning,error display_context_messages = notice -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers