Re: postgres.h included from relcache.h - but removing it breaks pg_upgrade - Mailing list pgsql-hackers

From Alexander Korotkov
Subject Re: postgres.h included from relcache.h - but removing it breaks pg_upgrade
Date
Msg-id CAPpHfdsnZeE7rT7U6+C_xYnAvZt+RRT2HPv3M7enZsEsqMfUuA@mail.gmail.com
Whole thread Raw
In response to Re: postgres.h included from relcache.h - but removing it breaks pg_upgrade  (Andres Freund <andres@anarazel.de>)
Responses Re: postgres.h included from relcache.h - but removing it breaks pg_upgrade
List pgsql-hackers
Hi,

On Sat, Sep 18, 2021 at 3:06 AM Andres Freund <andres@anarazel.de> wrote:
> On 2021-09-18 02:51:09 +0300, Alexander Korotkov wrote:
> > On Tue, Sep 14, 2021 at 6:53 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > > Without having looked at the details, I think using a forward-declare
> > > to avoid including relcache.h in visibilitymap.h might be a reasonably
> > > non-painful fix.
> >
> > I like that idea, but I didn't find an appropriate existing header for
> > forward-declaration of Relation.  relation.h isn't suitable, because
> > it includes primnodes.h.  A separate header for just
> > forward-definition of Relation seems too much.
>
> I was just thinking of doing something like the attached.

I see now.  I think I'm rather favoring splitting visibilitymap.h.

> > > TOH, in the long run it might be worth the effort
> > > to split visibilitymap.h to separate useful file-contents knowledge
> > > from backend function declarations.
> >
> > I've drafted a patch splitting visibilitymap_maros.h from
> > visibilitymap.h.  What do you think?
>
> I'd name it visibilitymapdefs.h or such, mostly because that's what other
> headers are named like...

Good point.  The revised patch is attached.

------
Regards,
Alexander Korotkov

Attachment

pgsql-hackers by date:

Previous
From: Zhihong Yu
Date:
Subject: Re: So, about that cast-to-typmod-minus-one business
Next
From: Alvaro Herrera
Date:
Subject: Re: postgres.h included from relcache.h - but removing it breaks pg_upgrade