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

From wangw.fnst@fujitsu.com
Subject RE: Support logical replication of DDLs
Date
Msg-id OS3PR01MB62752246D2A718126825A1809EB59@OS3PR01MB6275.jpnprd01.prod.outlook.com
Whole thread Raw
In response to RE: Support logical replication of DDLs  ("wangw.fnst@fujitsu.com" <wangw.fnst@fujitsu.com>)
Responses RE: Support logical replication of DDLs
List pgsql-hackers
On Mon, Mar 6, 2023 18:17 PM Wang, Wei/王 威 <wangw.fnst@fujitsu.com> wrote:
> On Mon, Mar 6, 2023 14:34 AM Ajin Cherian <itsajin@gmail.com> wrote:
> > Changes are in patch 1 and patch 2
> 
> Thanks for updating the patch set.
> 
> Here are some comments:

Here are some more comments for v-75-0002* patch:

1. In the function deparse_AlterRelation
+        if ((sub->address.objectId != relId &&
+             sub->address.objectId != InvalidOid) &&
+            !(subcmd->subtype == AT_AddConstraint &&
+              subcmd->recurse) &&
+            istable)
+            continue;
I think when we execute the command "ALTER TABLE ... CLUSTER ON" (subtype is
AT_ClusterOn), this command will be skipped for parsing. I think we need to
parse this command here.

I think we are skipping some needed parsing due to this check, such as [1].#1
and the AT_ClusterOn command mentioned above. After reading the thread, I think
the purpose of this check is to fix the bug in [2] (see the last point in [2]).
I think maybe we could modify this check to `continue` when
sub->address.objectId and relId are inconsistent and sub->address.objectId is a
child (inherited or partition) table. What do you think?

~~~

2. In the function deparse_CreateStmt
I think when we execute the following command:
    `CREATE TABLE tbl (a int GENERATED ALWAYS AS (1) STORED);`
the deparsed result is :
    `CREATE  TABLE  public.tbl (a pg_catalog.int4 STORAGE plain GENERATED ALWAYS AS 1 STORED);`
I think the parentheses around generation_expr(I mean `1`) are missing, which
would cause a syntax error.

~~~

3. In the function deparse_IndexStmt
I think we missed parsing of options [NULLS NOT DISTINCT] in the following
command:
```
CREATE UNIQUE INDEX ... ON table_name ... NULLS NOT DISTINCT;
```
I think we could check this option via node->nulls_not_distinct.

[1] -
https://www.postgresql.org/message-id/OS3PR01MB6275FE40496DA47C0A3369289EB69%40OS3PR01MB6275.jpnprd01.prod.outlook.com
[2] - https://www.postgresql.org/message-id/CAAD30UJ25nTPiVc0RTnsVbhHSNrnoqoackf9%2B%2BNa%2BR-QN6dRkw%40mail.gmail.com

Regards,
Wang wei

pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: Add pg_walinspect function with block info columns
Next
From: Amit Kapila
Date:
Subject: Re: Allow logical replication to copy tables in binary format