Re: Table AM Interface Enhancements

Поиск
Список
Период
Сортировка
От Pavel Borisov
Тема Re: Table AM Interface Enhancements
Дата
Msg-id CALT9ZEHyMrDbJ8ecfe311yw_incgYk5NYn-7xfpfvz30U3dp9A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Table AM Interface Enhancements  (Jeff Davis <pgsql@j-davis.com>)
Ответы Re: Table AM Interface Enhancements  (Alexander Korotkov <aekorotkov@gmail.com>)
Список pgsql-hackers
Hi, hackers!

On Tue, 2 Apr 2024 at 19:17, Jeff Davis <pgsql@j-davis.com> wrote:
On Tue, 2024-04-02 at 11:49 +0300, Alexander Korotkov wrote:
> I don't like the idea that every custom table AM reltoptions should
> begin with StdRdOptions.  I would rather introduce the new data
> structure with table options, which need to be accessed outside of
> table AM.  Then reloptions will be a backbox only directly used in
> table AM, while table AM has a freedom on what to store in reloptions
> and how to calculate externally-visible options.  What do you think?

Hi Alexander!

I agree with all of that. It will take some refactoring to get there,
though.

One idea is to store StdRdOptions like normal, but if an unrecognized
option is found, ask the table AM if it understands the option. In that
case I think we'd just use a different field in pg_class so that it can
use whatever format it wants to represent its options.

Regards,
        Jeff Davis
I tried to rework a patch regarding table am according to the input from Alexander and Jeff.

It splits table reloptions into two categories: 
- common for all tables (stored in a fixed size structure and could be accessed from outside) 
- table-am specific (variable size, parsed and accessed by access method only)

Please find a patch attached.
Вложения

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

Предыдущее
От: Nathan Bossart
Дата:
Сообщение: Re: WIP Incremental JSON Parser
Следующее
От: Dmitry Dolgov
Дата:
Сообщение: Re: broken JIT support on Fedora 40