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

From li jie
Subject Re: Support logical replication of DDLs
Date
Msg-id CAGfChW4w-Nbag8js_QmZQMqDBZ7Sgz=28BhQV0oka5VDyJhwWw@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  (Zheng Li <zhengli10@gmail.com>)
List pgsql-hackers
I applied patch 0005.

I think this modification is a bit overdone.
This design skips all subcommands, which results in many ddl
replication failures.
For example:
```
CREATE TABLE datatype_table (id SERIAL);
```
deparsed ddl is:
CREATE  TABLE  public.datatype_table (id pg_catalog.int4 STORAGE plain
NOT NULL DEFAULT
pg_catalog.nextval('public.datatype_table_id_seq'::pg_catalog.regclass))
CREATE SEQUENCE subcommand will be skipped.

OR:
```
CREATE SCHEMA element_test
CREATE TABLE foo (id int)
CREATE VIEW bar AS SELECT * FROM foo;
```
deparsed ddl is:
CREATE SCHEMA element_test.

Its subcommands will be skipped.
There may be other cases.

For the initial CREATE LIKE statement, It is special,
It derives the subcommand of alter table column.
Just skipping them may be enough.
Instead of skipping subcommands of all statements.
After all, our design is to obtain the actual ddl information from the
catalog instead of parsing raw parsetree.
This is why we cannot skip all subcommands.

Do you have any better ideas?

Regards, Adger.



pgsql-hackers by date:

Previous
From: Ranier Vilela
Date:
Subject: Optimizing Node Files Support
Next
From: Kazutaka Onishi
Date:
Subject: Re: Asynchronous execution support for Custom Scan