On Wed, Apr 29, 2026 at 1:25 AM Hannu Krosing <[email protected]> wrote: > > My high-level understanding is, that we should first clearly answer these two > questions > > 1. What does Logical Decodng infrastructure make available to the decoding > plugin call-backs > > 2. What the callbacks themselves do in case of DDL
Yeah that makes sense, Hannu. > My answer to the 1. is "everything, as it should be the plugin that decides > what it needs". It does not mean that we should always prepack everything > with special logical decoding structures, but there should be a way to get at > anything that is available in the WAL at least. The result is in WAL, and for > DDL it is also in the system tables themselves, in proper time-travel way. > > For 2. I would prefer to "deparse" the DDL from actual system tables at that > snapshot. In logical decoding the system tables are special in that we keep > the actual table content and have real time travel capabilities on them. This > should allow us to use the code we already have in pg_dump for extracting the > "status quo DDL" meaning the DDL for creating everything from scratch. The > main thing missing is DDL for ALTER and DROP which would need to be added. > But that too should be in the plugin, not in the DDL side . I am trying to understand your idea. If we are trying to deparse from an actual system table using a snapshot, why don't we just use the WAL? I mean, the WAL should contain the actual catalog modifications it has made. Although converting the catalog changes into a deparse representation of the DDL could be complex no? Another question is what we would do with those deparsed representations: will we convert them to SQL on the subscriber and execute, or do something else? -- Regards, Dilip Kumar Google
