Re: DDL deparse

Dear Hackers,

> So my question is: should DDL deparse preserve user intent, or is it
> acceptable to materialize the catalog state (in which case, should we
> just extend pg_get_table_ddl instead)?

I think, it depends on the usage scenarios. There are some use cases of:
major upgrade, replication to other databases, replication to other
cliends, DDL mining from WAL, logging and audit. In case of replication to
other databases, splitting a complex command to a number of simple commands
that materialize the same schema looks ok. In case of DDL mining from WAL
or logging and audit scenarios it would be preferable to keep user intent.

Sorry for off-topic, but I'm still not sure that deparsing the original DDL
command from the parse tree is the best approach. Below are some problem
queries for deparsing original DDL from the parse tree.

Query 1: CTAS with function

CREATE OR REPLACE FUNCTION f1()
RETURNS integer
AS $$
CREATE TABLE t2(c INT);
SELECT 10;
$$
LANGUAGE SQL;

CREATE TABLE t AS SELECT f1();

Query 2: CTAS with a temp table

CREATE TABLE t AS SELECT * FROM temptable;

Query 3: CTAS with a function parameter

CREATE TABLE t AS SELECT @mypar

Decoding final changes in the WAL seems to be the more suitable approach
for such cases.

Adding a new data into the WAL like a new record type with original DDL for
for logical decoding seems redundant. Decoding system catalog changes from
the WAL with some new hints may help to decode the commands like
ALTER TABLE ALTER COLUMN TYPE USING. Defining user command boundaries in the
WAL may help to decode the original command as well.

With best regards,
Vitaly