Hi, On Sat, Apr 26, 2025 at 02:55:51PM -0400, Tom Lane wrote: > Bertrand Drouvot <bertranddrouvot...@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
