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