Re: Add pg_stat_recovery system view

> On Mar 6, 2026, at 23:45, 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

Hi Tom, Thanks for the detailed explanation. Noted.

Would it make sense to mention this distinction in the header comments for ereport and elog in the code? For these logging APIs, I think developers are often more likely to read the code comments than the documentation.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/