Re: Support for detailed description of errors cased by trigger-violations - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Support for detailed description of errors cased by trigger-violations
Date
Msg-id 32076.1415486390@sss.pgh.pa.us
Whole thread Raw
In response to Support for detailed description of errors cased by trigger-violations  (Andreas Joseph Krogh <andreas@visena.com>)
Responses Re: Support for detailed description of errors cased by trigger-violations  (Andreas Joseph Krogh <andreas@visena.com>)
List pgsql-hackers
Andreas Joseph Krogh <andreas@visena.com> writes:
> Hi.   When working with Oracle it is possible to catch constraint-violations 
> caused by triggers using JDBC, but it seems this isn't possible using PG, see 
> this thread: 
> https://github.com/impossibl/pgjdbc-ng/issues/111#issuecomment-62276464

I'm not exactly following the point.  The complaint seems to be that
   RAISE EXCEPTION 'ID must be less then 10';

doesn't send anything except the given primary message and a generic
SQLSTATE.  Well, duh: it's not supposed to.  There are a bunch of options
you can supply in RAISE to populate additional fields of the error report.
For example, you could add
   USING SCHEMA = TG_TABLE_SCHEMA, TABLE = TG_TABLE_NAME

if you wanted the report to name the table the trigger is attached to.

So it seems to me this is lazy plpgsql programming, not a missing feature.
It would only be a missing feature if you think plpgsql should try to
auto-populate these fields; but I'd be against that because it would
require too many assumptions about exactly what the function might be
complaining about.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: pg_multixact not getting truncated
Next
From: Robert Haas
Date:
Subject: Re: Add CREATE support to event triggers