Re: postgres.h included from relcache.h - but removing it breaks pg_upgrade
| От | Andres Freund |
|---|---|
| Тема | Re: postgres.h included from relcache.h - but removing it breaks pg_upgrade |
| Дата | |
| Msg-id | 20210918000655.hcrp2po7qu7jcmq7@alap3.anarazel.de обсуждение исходный текст |
| Ответ на | Re: postgres.h included from relcache.h - but removing it breaks pg_upgrade (Alexander Korotkov <aekorotkov@gmail.com>) |
| Ответы |
Re: postgres.h included from relcache.h - but removing it breaks pg_upgrade
|
| Список | pgsql-hackers |
Hi, 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. > > 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... Greetings, Andres Freund
Вложения
В списке pgsql-hackers по дате отправления: