Re: Support logical replication of DDLs

Поиск
Список
Период
Сортировка
От Zheng Li
Тема Re: Support logical replication of DDLs
Дата
Msg-id CAAD30UKv-VYyd2DBt-RzG9eL3V_E4tbGWmTYpvLjmzyT4ikVAQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Support logical replication of DDLs  (vignesh C <vignesh21@gmail.com>)
Ответы RE: Support logical replication of DDLs  ("Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>)
Список pgsql-hackers
On Tue, Jun 27, 2023 at 6:16 AM vignesh C <vignesh21@gmail.com> wrote:

> While development, below are some of the challenges we faced:

> 1. Almost all the members of the AlterTableType enum will have to be annotated.
> 2. Complex functionalities which require access to catalog tables
> cannot be auto generated, custom functions should be written in this
> case.
> 3. Some commands might have completely custom code(no auto generation)
> and in the alter/drop table case we will have hybrid implementation
> both auto generated and custom implementation.

Thanks for providing the PoC for auto generation of the deparser code!

I think this is the main difference between the deparser code and outfuncs.c.
There is no need for catalog access in outfuncs.c, which makes code generation
simpler for outfuncs.c and harder for the deparser. The hybrid
implementation of the deparser doesn't seem
to make it more maintainable, it's probably more confusing. Is it possible to
automate the code with catalog access? There may be common patterns in it also.

Regards,
Zane



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

Предыдущее
От: reid.thompson@crunchydata.com
Дата:
Сообщение: Re: DecodeInterval fixes
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: BRIN indexes vs. SK_SEARCHARRAY (and preprocessing scan keys)