Re: Support logical replication of DDLs - Mailing list pgsql-hackers

From Zheng Li
Subject Re: Support logical replication of DDLs
Date
Msg-id CAAD30UKv-VYyd2DBt-RzG9eL3V_E4tbGWmTYpvLjmzyT4ikVAQ@mail.gmail.com
Whole thread Raw
In response to Re: Support logical replication of DDLs  (vignesh C <vignesh21@gmail.com>)
Responses RE: Support logical replication of DDLs  ("Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>)
List 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 by date:

Previous
From: reid.thompson@crunchydata.com
Date:
Subject: Re: DecodeInterval fixes
Next
From: Tomas Vondra
Date:
Subject: Re: BRIN indexes vs. SK_SEARCHARRAY (and preprocessing scan keys)