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

From Tom Lane
Subject Re: Add pg_stat_recovery system view
Date
Msg-id 297458.1772811905@sss.pgh.pa.us
Whole thread Raw
In response to Re: Add pg_stat_recovery system view  (Chao Li <li.evan.chao@gmail.com>)
Responses Re: Add pg_stat_recovery system view
Re: Add pg_stat_recovery system view
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Álvaro Herrera
Date:
Subject: Re: Rework SLRU I/O errors handle
Next
From: Xuneng Zhou
Date:
Subject: Re: Add pg_stat_recovery system view