Hi,
On Sat, Apr 26, 2025 at 02:55:51PM -0400, Tom Lane wrote:
> Bertrand Drouvot <bertranddrouvot.pg@gmail.com> writes:
> > On Sat, Apr 26, 2025 at 01:20:56AM -0400, Tom Lane wrote:
> >> Whatever it contains, we need to kill it with fire before the problem
> >> metastasizes like it did the last time. (yeah, yeah, badly mixed
> >> metaphors) I can take a look at this one over the weekend if nobody
> >> beats me to it.
>
> > I had a look at it, what do you think about 0002 attached? (Not 100% sure
> > that's the best approach though).
>
> After looking at this,
Thanks!
> I think the actual problem is that plpython.h
> does this:
>
> /*
> * Used throughout, so it's easier to just include it everywhere.
> */
> #include "plpy_util.h"
Agree.
> which is exactly the sort of cowboy modularity violation that hurts
> when you have to clean it up. Taking that out requires having to
> manually include plpy_util.h in all the relevant .c files, but on
> the other hand we can remove their vestigial direct inclusions of
> plpython.h. It was always pretty silly to #include that after
> including some plpy_foo.h files, so let's stop doing so. The attached
> patch therefore boils down in most places to s/plpython.h/plpy_util.h/.
>
> (A small number of these files still compiled without that, indicating
> that they're not actually using plpy_util.h today. But I figured we
> might as well just do it uniformly.)
Yeah, makes sense. I checked the s/plpython.h/plpy_util.h/ replacements and
the includes alphabetical ordering is still preserved. Also misc-header-include-cycle
is now happy so LGTM.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
