Re: postgres.h included from relcache.h - but removing it breaks pg_upgrade
Alexander Korotkov <aekorotkov@gmail.com>
From: Alexander Korotkov <aekorotkov@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
pgsql-hackers <pgsql-hackers@postgresql.org>, Alexander Korotkov <akorotkov@postgresql.org>
Date: 2021-09-18T18:58:36Z
Lists: pgsql-hackers
Attachments
- 0001-Split-macros-from-visibilitymap.h-into-a-separate--2.patch (application/x-patch) patch 0001
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
Commits
-
Split macros from visibilitymap.h into a separate header
- fd22aec631af 13.5 landed
- 7186f07189ba 14.0 landed
- b92f9f74436c 15.0 landed
-
Implement operator class parameters
- 911e70207703 13.0 cited