Re: Making pgfdw_report_error statically analyzable

2025-07-29 Thread Tom Lane
I wrote: > I'll run with Alvaro's suggestion, then. And done. In the event I realized that there's no point in back-patching this, because 80aa9848b already changed all the call sites of pgfdw_report_error, so we're already going to have issues back-patching any fixes that touch those.

Re: Making pgfdw_report_error statically analyzable

2025-07-29 Thread Tom Lane
Robert Haas writes: > On Mon, Jul 28, 2025 at 5:30 PM Tom Lane wrote: >> =?utf-8?Q?=C3=81lvaro?= Herrera writes: >>> Hmm, what about 2c. having pgfdw_report_error() with hardcoded elevel, >>> but complement it with pgfdw_report() that takes the elevel as argument, >>> asserting that it's less th

Re: Making pgfdw_report_error statically analyzable

2025-07-29 Thread Robert Haas
On Mon, Jul 28, 2025 at 5:30 PM Tom Lane wrote: > =?utf-8?Q?=C3=81lvaro?= Herrera writes: > > Hmm, what about 2c. having pgfdw_report_error() with hardcoded elevel, > > but complement it with pgfdw_report() that takes the elevel as argument, > > asserting that it's less than ERROR? Then the call

Re: Making pgfdw_report_error statically analyzable

2025-07-28 Thread Tom Lane
=?utf-8?Q?=C3=81lvaro?= Herrera writes: > Hmm, what about 2c. having pgfdw_report_error() with hardcoded elevel, > but complement it with pgfdw_report() that takes the elevel as argument, > asserting that it's less than ERROR? Then the calls look like > pgfdw_report(WARNING, "doo dee"); > whic

Re: Making pgfdw_report_error statically analyzable

2025-07-28 Thread Álvaro Herrera
On 2025-Jul-28, Tom Lane wrote: > 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 > i

Re: Making pgfdw_report_error statically analyzable

2025-07-28 Thread Tom Lane
Robert Haas writes: > On Mon, Jul 28, 2025 at 10:55 AM Tom Lane 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

Re: Making pgfdw_report_error statically analyzable

2025-07-28 Thread Robert Haas
On Mon, Jul 28, 2025 at 10:55 AM Tom Lane 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 pg