Re: Making pgfdw_report_error statically analyzable

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Jul 28, 2025 at 10:55 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 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.

The difference between 2a and 2b is just cosmetic really, so
I'm fine to go with 2b if that's the consensus.

regards, tom lane