Re: Extensible Rmgr for Table AMs - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Extensible Rmgr for Table AMs
Date
Msg-id CA+TgmoYivHY9SzD3EEQtCDO+hpUJkD8TRG-gfBsLrMz7f43kJA@mail.gmail.com
Whole thread Raw
In response to Re: Extensible Rmgr for Table AMs  (Julien Rouhaud <rjuju123@gmail.com>)
Responses Re: Extensible Rmgr for Table AMs
List pgsql-hackers
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.

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



pgsql-hackers by date:

Previous
From: Julien Rouhaud
Date:
Subject: Re: Extensible Rmgr for Table AMs
Next
From: Julien Rouhaud
Date:
Subject: Re: Extensible Rmgr for Table AMs