Re: Making pgfdw_report_error statically analyzable

On Mon, Jul 28, 2025 at 10:55 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I can see two, or two-and-a-half, ways to do that:
>
> 1. Wrap pgfdw_report_error in a macro that makes use of pg_unreachable
> in a way similar to what we've done for elog/ereport. The argument
> for this is that we needn't touch the 30-or-so pgfdw_report_error
> call sites; the argument against is that those elog/ereport macros
> are messy, compiler-dependent, and keep needing changes.
>
> 2a. Split pgfdw_report_error into two functions, say
> pgfdw_report_error() that hard-wires elevel as ERROR and is
> labeled noreturn, and pgfdw_report_noerror() that has an
> elevel argument that it asserts is less than ERROR.
>
> 2b. As 2a except the two functions are pgfdw_report_error()
> and pgfdw_report_warning(), both with hard-wired elevel values.
> This'd be sufficient right now, but it's plausible that this path
> would lead to needing pgfdw_report_log() and some other variants
> in future.

I would be fine with any of these, but my order of preference would
probably be #2b-#1-#2a i.e. I like your most-preferred alternative
least. However, it's a very mild preference so I am more than fine if
you want to just go ahead and do #2a as you proposed.

--
Robert Haas
EDB: http://www.enterprisedb.com