Re: Add pg_stat_recovery system view - Mailing list pgsql-hackers

From Xuneng Zhou
Subject Re: Add pg_stat_recovery system view
Date
Msg-id CABPTF7Ut6_pvEi3mn=7OEFd5YwFgOJNe1+GyFPJSiWxRueT5ag@mail.gmail.com
Whole thread Raw
In response to Re: Add pg_stat_recovery system view  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi Tom,

On Fri, Mar 6, 2026 at 11:45 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Chao Li <li.evan.chao@gmail.com> writes:
> > I have one small additional comment on pushed 0001.
> > ```
> >     if (get_call_result_type(fcinfo, NULL, &tupdesc) != TYPEFUNC_COMPOSITE)
> >          elog(ERROR, "return type must be a row type");
> > ```
>
> > This uses elog(ERROR), while the other functions in the same file use ereport(ERROR). I think ereport is generally
preferrednowadays over elog. 
>
> No: you are incorrect and this snippet is perfectly normal (in fact,
> probably copied-and-pasted from one of many other occurrences).
> The actual coding rule is basically "use ereport() for user-facing
> errors and elog() for not-supposed-to-happen errors".  What we're
> after is to not expend translator effort on not-supposed-to-happen
> error messages.  While you can build a ereport call that's not
> translated, elog() is a lower-notation way to get the same result.
> See [1], particularly the elog() discussion near the end of the
> page.
>
> I've not read the patch so I don't know if it made sane ereport-vs-
> elog choices elsewhere, but this one is fine.
>
>                         regards, tom lane
>
> [1] https://www.postgresql.org/docs/devel/error-message-reporting.html

Thanks for your clarification!

--
Best,
Xuneng



pgsql-hackers by date:

Previous
From: Xuneng Zhou
Date:
Subject: Re: Add pg_stat_recovery system view
Next
From: Tom Lane
Date:
Subject: Re: Allow specifying NULL default in pg_proc.dat for "any" arguments