Re: Add pg_stat_recovery system view

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