I believe the availability of trapping the error codes and raising the appropriate message is already in PLPGSQL. Please see the two sections below.
http://www.postgresql.org/docs/9.4/interactive/plpgsql-control-structures.html#PLPGSQL-ERROR-TRAPPING http://www.postgresql.org/docs/9.4/interactive/errcodes-appendix.html On Thu, Apr 2, 2015 at 12:01 PM, Taytay <tay...@youneedabudget.com> wrote: > 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] <[hidden > email] <http:///user/SendEmail.jtp?type=node&node=5844473&i=0>> 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. >> 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: Re: Why doesn't `RAISE EXCEPTION` provide > error context? > <http://postgresql.nabble.com/Why-doesn-t-RAISE-EXCEPTION-provide-error-context-tp5844382p5844473.html> > Sent from the PostgreSQL - general mailing list archive > <http://postgresql.nabble.com/PostgreSQL-general-f1843780.html> at > Nabble.com. > -- *Melvin Davidson* I reserve the right to fantasize. Whether or not you wish to share my fantasy is entirely up to you.
