Re: Add pg_stat_recovery system view

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