Re: Extensible Rmgr for Table AMs
От | Julien Rouhaud |
---|---|
Тема | Re: Extensible Rmgr for Table AMs |
Дата | |
Msg-id | 20220204145658.qtcmbsdawvn3lg3b@jrouhaud обсуждение исходный текст |
Ответ на | Re: Extensible Rmgr for Table AMs (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Extensible Rmgr for Table AMs
|
Список | pgsql-hackers |
On Fri, Feb 04, 2022 at 09:53:09AM -0500, Robert Haas wrote: > On Fri, Feb 4, 2022 at 9:48 AM Julien Rouhaud <rjuju123@gmail.com> wrote: > > I guess the idea was to have a compromise between letting rmgr authors choose > > arbitrary ids to avoid any conflicts, especially with private implementations, > > without wasting too much memory. But those approaches would be pretty much > > incompatible with the current definition: > > > > +#define RM_CUSTOM_MIN_ID 128 > > +#define RM_CUSTOM_MAX_ID UINT8_MAX > > > > even if you only allocate up to the max id found, nothing guarantees that you > > won't get a quite high id. > > Right, which I guess raises another question: if the maximum is > UINT8_MAX, which BTW I find perfectly reasonable, why are we not just > defining this as an array of size 256? There's no point in adding code > complexity to save a few kB of memory. Agreed, especially if combined with your suggested approach 3 (array of pointers).
В списке pgsql-hackers по дате отправления: