MIME-Version: 1.0
References: 
 <OSZPR01MB63102C42A24D59FACF6D9CD6FD4A9@OSZPR01MB6310.jpnprd01.prod.outlook.com>
 <CAJpy0uCbwqWj+p_yj1AHyiufzAUv_H29qOaztAXxFoTqZ9WcAw@mail.gmail.com>
 <OSZPR01MB6310E0509F229AF2A9414BB1FD499@OSZPR01MB6310.jpnprd01.prod.outlook.com>
 <CAJpy0uBwCZCniPR6vh26L+wpSf4xzUN8omUa9DzF-x1CAud_xA@mail.gmail.com>
 <CAA4eK1LOr+2O+_pWKTaa0y9vbW6whfm-8-fuBvnS6OBiaR+7TA@mail.gmail.com>
 <CAA4eK1LF3EaCSj5iqO0oT1k3ew7YnQbbKEgbzORDAdvdtd+r7w@mail.gmail.com>
 <CAJpy0uDtrxPo127LH3FP-TffynrspPFqhhC7o_GFOMP+2mPtWQ@mail.gmail.com>
 <OS3PR01MB6275328379FBE5734B4585619E54A@OS3PR01MB6275.jpnprd01.prod.outlook.com>
 <ZIgf3qBvFoTsMhIc@paquier.xyz>
 <CAA4eK1J8WOK9VZ9RpQRNRhRYhFOKQCu=GLCu+iBOePNO3JwLbQ@mail.gmail.com>
 <ZIjmGhPWdoJUfjjE@paquier.xyz>
 <CAJpy0uDaubBHyqPc1k0OysuBYDOVdoUgTWG4jXDCYj-OVSU8hg@mail.gmail.com>
In-Reply-To: 
 <CAJpy0uDaubBHyqPc1k0OysuBYDOVdoUgTWG4jXDCYj-OVSU8hg@mail.gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
Date: Mon, 19 Jun 2023 15:04:07 +0530
Message-ID: 
 <CAA4eK1+K8KMsB=+jJO6wDUSt7wF1RiXKtF-HN48nCOEOv-J-3Q@mail.gmail.com>
Subject: Re: Support logical replication of DDLs
To: shveta malik <shveta.malik@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>,
 "Wei Wang (Fujitsu)" <wangw.fnst@fujitsu.com>,
	"Yu Shi (Fujitsu)" <shiy.fnst@fujitsu.com>, vignesh C <vignesh21@gmail.com>,
	"Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>,
 Ajin Cherian <itsajin@gmail.com>,
	Runqi Tian <runqidev@gmail.com>, Peter Smith <smithpb2250@gmail.com>,
 Tom Lane <tgl@sss.pgh.pa.us>,
	li jie <ggysxcq@gmail.com>, Dilip Kumar <dilipbalaut@gmail.com>,
	Alvaro Herrera <alvherre@alvh.no-ip.org>,
 Masahiko Sawada <sawada.mshk@gmail.com>,
	Japin Li <japinli@hotmail.com>, rajesh singarapu <rajesh.rs0541@gmail.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
 Zheng Li <zhengli10@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAA4eK1%2BK8KMsB%3D%2BjJO6wDUSt7wF1RiXKtF-HN48nCOEOv-J-3Q%40mail.gmail.com>
Precedence: bulk

On Fri, Jun 16, 2023 at 4:01=E2=80=AFPM shveta malik <shveta.malik@gmail.co=
m> wrote:
>
> With these changes, I hope the patch-set is somewhat easier to review.
>

Few comments:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
1.
+static Jsonb *
+deparse_CreateStmt(Oid objectId, Node *parsetree)
{
...
+ /* PERSISTENCE */
+ appendStringInfoString(&fmtStr, "CREATE %{persistence}s TABLE");
+ new_jsonb_VA(state, NULL, NULL, false, 1,
+ "persistence", jbvString,
+ get_persistence_str(relation->rd_rel->relpersistence));

Do we need to add key/value pair if get_persistence_str() returns an
empty string in the default deparsing mode? Won't it be somewhat
inconsistent with other objects?

2.
+static JsonbValue *
+new_jsonb_VA(JsonbParseState *state, char *parentKey, char *fmt,
+ bool createChildObj, int numobjs,...)
+{
+ va_list args;
+ int i;
+ JsonbValue val;
+ JsonbValue *value =3D NULL;
+
+ /*
+ * Insert parent key for which we are going to create value object here.
+ */
+ if (parentKey)
+ insert_jsonb_key(state, parentKey);
+
+ /* Set up the toplevel object if not instructed otherwise */
+ if (createChildObj)
+ pushJsonbValue(&state, WJB_BEGIN_OBJECT, NULL);
+
+ /* Set up the "fmt" */
+ if (fmt)
+ fmt_to_jsonb_element(state, fmt);

I think it would be better to handle parentKey, childObj, and fmt in
the callers as this function doesn't seem to be the ideal place to
deal with those. I see that in some cases we already handle those in
the callers. It is bit confusing in which case callers need to deal
vs. the cases where we need to deal here.

3.
+static Jsonb *
+deparse_AlterSeqStmt(Oid objectId, Node *parsetree)
{
...
+
+ new_jsonb_VA(state, NULL, "ALTER SEQUENCE %{identity}D %{definition: }s",
+ false, 0);

Is there a need to call new_jsonb_VA() just to insert format? Won't it
better to do this in the caller itself?

4. The handling for if_not_exists appears to be different in
deparse_CreateSeqStmt() and deparse_CreateStmt(). I think the later
one is correct and we should do that in both places. That means
probably we can't have the entire format key in the beginning of
deparse_CreateSeqStmt().

5.
+ /*
+ * Check if table elements are present, if so, add them. This function
+ * call takes care of both the check and addition.
+ */
+ telems =3D insert_table_elements(state, &fmtStr, relation,
+    node->tableElts, dpcontext, objectId,
+    false, /* not typed table */
+    false); /* not composite */

Would it be better to name this function to something like
add_table_elems_if_any()? If so, we can remove second part of the
comment: "This function call takes care of both the check and
addition." as that would be obvious from the function name.

6.
+ /*
+ * Check if table elements are present, if so, add them. This function
+ * call takes care of both the check and addition.
+ */
+ telems =3D insert_table_elements(state, &fmtStr, relation,
+    node->tableElts, dpcontext, objectId,
+    false, /* not typed table */
+    false); /* not composite */
+
+ /*
+ * If no table elements added, then add empty "()" needed for 'inherit'
+ * create table syntax. Example: CREATE TABLE t1 () INHERITS (t0);
+ */
+ if (!telems)
+ appendStringInfoString(&fmtStr, " ()");

In insert_table_elements(), sometimes we access system twice for each
of the columns and this is to identify the above case where no
elements are present. Would it be better if simply for zero element
object array in this case and detect the same on the receiving side?
If this is feasible then we can simply name the function as
add_table_elems/add_table_elements. Also, in this context, can we
change the variable name telems to telems_present to make it bit easy
to follow.

7. It would be better if we can further split the patch to move Alter
case into a separate patch. That will help us to focus on reviewing
Create/Drop in detail.

--=20
With Regards,
Amit Kapila.