Re: plperl error format vs plpgsql error format vs pgTAP

From: Kevin Field <kevinjamesfield(at)gmail(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: plperl error format vs plpgsql error format vs pgTAP
Date: 2009-06-01 16:01:06
Message-ID: a4d2c042-8492-4d9e-99d3-14443e4811e9@v4g2000vba.googlegroups.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On May 29, 1:04 pm, t(dot)(dot)(dot)(at)sss(dot)pgh(dot)pa(dot)us (Tom Lane) wrote:
> Kevin Field <kevinjamesfi(dot)(dot)(dot)(at)gmail(dot)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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2009-06-01 16:02:15 Re: pg_migrator and an 8.3-compatible tsvector data type
Previous Message Robert Haas 2009-06-01 15:39:15 Re: pg_migrator and an 8.3-compatible tsvector data type