Re: plperl error format vs plpgsql error format vs pgTAP - Mailing list pgsql-hackers

From Kevin Field
Subject Re: plperl error format vs plpgsql error format vs pgTAP
Date
Msg-id a4d2c042-8492-4d9e-99d3-14443e4811e9@v4g2000vba.googlegroups.com
Whole thread Raw
In response to plperl error format vs plpgsql error format vs pgTAP  (Kevin Field <kevinjamesfield@gmail.com>)
List pgsql-hackers
On May 29, 1:04 pm, t...@sss.pgh.pa.us (Tom Lane) wrote:
> Kevin Field <kevinjamesfi...@gmail.com> writes:
> > default:
> >                            elog(ERROR, "unrecognized raise option: %d", opt->opt_type);
> > Should this be changed to:
> > default:
> >                            ereport(ERROR, (errmsg_internal("unrecognized raise option: %d",
> > opt->opt_type)));
>
> No, we generally don't bother with that.  The above two are exactly
> equivalent and the first is easier to write, so why complicate the code?
> ereport is needed if you want to specify a SQLSTATE, provide a
> translatable error message, etc, but for internal shouldn't-happen cases
> we customarily just use elog.

Ah, I had missed that.  I understand.  The function's comment's still
out of date though, I think, since it uses ereport at the end.


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: It's June 1; do you know where your release is?
Next
From: Simon Riggs
Date:
Subject: Re: Feedback on writing extensible modules