There appears to be a fair amount of nuance here, but I am _very_ impressed with how quickly you have responded. Thank you for your quick attention to this issue! (Yet another thing that makes me happy to be using Postgres).
We have fair amount of business logic in Postgres functions, and the ability to throw and catch exceptions, and pinpoint their source location in our logs, will be _very_ helpful for us. I look forward to it. This is perhaps a separate discussion, but as I await this patch, I'm looking for a way to "trick" Postgres into throwing an exception that will include a string of my choosing. Something like "SELECT 'This is an exception' / 0 " That would give me a "real" exception that is not subject to this filtering, and if the error message was "Divide by zero: 'This is an exception cannot' / 0" I'm totally making that up of course, but you see what I'm getting at. Does someone with better Postgres/SQL knowledge know of such an exception? Thanks again, Taylor On Thu, Apr 2, 2015 at 2:07 AM, Pavel Stehule [via PostgreSQL] < ml-node+s1045698n5844393...@n5.nabble.com> wrote: > > > > The OP on this thread has introduced a potential compromise. Keep the >> current printing behavior for RAISE but the construction of the error >> itself should contain all of the relevant detail so that the caller can get >> to the suppressed information via, in this instance, GET STACKED >> DIAGNOSTICS inside an exception handler - a situation where the error is in >> context but has not yet been printed. >> >> Giving the function author the ability, via a new using clause, to bypass >> the printing short-circuit is another feature to consider. >> >> I haven't fully comprehended the design decisions and trade-offs but >> omitting data to facilitate printing doesn't sound like an appropriate >> solution - not that I have any clue how hard it would be separate the two >> aspects. Likewise with adding in a short-circuit that is judgemental >> without providing some means to bypass it. We are not talking about data >> integrity or performance here and while I'll admit reducing verbosity is a >> valid goal mis-use of a provided work-around mechanic is not that serious a >> transgression and one readily noticed and somewhat readily corrected. >> > > There is more aspects - current behave is too simply fix - but it works > almost time. We can enhance a RAISE statement, but default behave should be > practical. Usually we don't need stack for NOTICE level (and maybe for > WARNING level) and usually we would to have stack for EXCEPTION level. Now, > there is workaround due GET DIAGNOSTICS STACK, but it is workaround - and > the enhancing of GET DIAGNOSTICS was not designed for this purpose. Sure, > there are more variant of fixing - and we can implement more than one. > > Regards > > Pavel > > >> >> David J. >> > > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://postgresql.nabble.com/Why-doesn-t-RAISE-EXCEPTION-provide-error-context-tp5844382p5844393.html > To unsubscribe from Why doesn't `RAISE EXCEPTION` provide error context?, > click > here > <http://postgresql.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5844382&code=dGF5bG9yQHlvdW5lZWRhYnVkZ2V0LmNvbXw1ODQ0MzgyfC03ODA0MjA3NDE=> > . > NAML > <http://postgresql.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> > -- View this message in context: http://postgresql.nabble.com/Why-doesn-t-RAISE-EXCEPTION-provide-error-context-tp5844382p5844473.html Sent from the PostgreSQL - general mailing list archive at Nabble.com.
