2015-04-24 13:16 GMT+02:00 Robert Haas <robertmh...@gmail.com>: > On Fri, Apr 24, 2015 at 6:11 AM, Joel Jacobson <j...@trustly.com> wrote: > > 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 > > This is a very flexible proposal, but it's a tremendous amount of > machinery for what's really a very minor issue. If we added two GUCs > for every comparably important issue, we'd have about 40,000 of them. >
It can be PLpgSQL only GUC. Probably it is a most problematic case. > > I suggest we add the RAISE syntax first, because everybody agrees on > that. Then, we can argue about the other stuff. > There is a agreement about it - but I am expecting a harder discussion about what will be default, and the discussion about syntax should not be simple too. > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >
