Re: Add pg_stat_recovery system view

Hi Tom,

On Fri, Mar 6, 2026 at 11:45 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Chao Li <li(dot)evan(dot)chao(at)gmail(dot)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 preferred nowadays 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