Re: making relfilenodes 56 bits

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: making relfilenodes 56 bits
Дата
Msg-id CA+Tgmoa9-0GTw=nR-3QXQ6U4GrR9h5OGD4zjbGACuCCQCKEo8g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: making relfilenodes 56 bits  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Ответы Re: making relfilenodes 56 bits  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Список pgsql-hackers
On Fri, Jul 29, 2022 at 2:12 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> On 2022-Jul-29, Robert Haas wrote:
> > I was taught that when programming in C one should avoid returning a
> > struct type, as BufTagGetRelFileLocator does.
>
> Doing it like that helps RelFileLocatorSkippingWAL, which takes a bare
> RelFileLocator as argument.  With this coding you can call one function
> with the other function as its argument.
>
> However, with the current definition of relpathbackend() and siblings,
> it looks quite disastrous -- BufTagGetRelFileLocator is being called
> three times.  You could argue that a solution would be to turn those
> macros into static inline functions.

Yeah, if we think it's OK to pass around structs, then that seems like
the right solution. Otherwise functions that take RelFileLocator
should be changed to take const RelFileLocator * and we should adjust
elsewhere accordingly.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: pg15b2: large objects lost on upgrade
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: enable/disable broken for statement triggers on partitioned tables