Re: postgres.h included from relcache.h - but removing it breaks pg_upgrade
| От | Alexander Korotkov |
|---|---|
| Тема | Re: postgres.h included from relcache.h - but removing it breaks pg_upgrade |
| Дата | |
| Msg-id | CAPpHfduP6G7m-e=9o50NqES3+21BV9hUa-VvSbB3drf0U_+aPA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: postgres.h included from relcache.h - but removing it breaks pg_upgrade (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: postgres.h included from relcache.h - but removing it breaks pg_upgrade
|
| Список | pgsql-hackers |
On Tue, Sep 14, 2021 at 6:53 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Andres Freund <andres@anarazel.de> writes: > > On 2021-09-13 22:40:19 -0400, Tom Lane wrote: > >> As for the fix ... what in the world is pg_upgrade doing including > >> relcache.h? It seems like there's a more fundamental problem here: > >> either relcache.h is declaring something that needs to be elsewhere, > >> or pg_upgrade is doing something it should not. > > > We could split visibilitymap.h into two, or we could forward-declare Relation > > and not include relcache... > > 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. > 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? ------ Regards, Alexander Korotkov
Вложения
В списке pgsql-hackers по дате отправления: