From: | "houzj(dot)fnst(at)fujitsu(dot)com" <houzj(dot)fnst(at)fujitsu(dot)com> |
---|---|
To: | vignesh C <vignesh21(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Smith <smithpb2250(at)gmail(dot)com>, "tanghy(dot)fnst(at)fujitsu(dot)com" <tanghy(dot)fnst(at)fujitsu(dot)com>, Greg Nancarrow <gregn4422(at)gmail(dot)com>, Ajin Cherian <itsajin(at)gmail(dot)com>, Rahila Syed <rahilasyed90(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
Subject: | RE: Added schema level support for publication. |
Date: | 2021-09-10 02:33:16 |
Message-ID: | OS0PR01MB5716F72CE944E386C4C75F0C94D69@OS0PR01MB5716.jpnprd01.prod.outlook.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
From Wed, Sept 8, 2021 7:44 PM vignesh C <vignesh21(at)gmail(dot)com> wrote:
> Modified
> Thanks for the comments, the attached v26 patch has the changes for the same.
Hi,
Thanks for updating the patch, I have a suggestion for the gram.y.
Currently, we have the following two members in PublicationObjSpec to distinguish
between names of different objects for the post-analysis phase.
>bool inh;
>bool spl_rel_type_syn;
I was thinking do we have another way to distinguish that which can make code
smaller. I tried serval approaches and found a possible better approach.
First, I refer to the design of Grant/Revoke syntax, it use two members
'targtype' and 'objtype' to mark different type. 'targtype' can be
ACL_TARGET_OBJECT(single target) or ACL_TARGET_ALL_IN_SCHEMA(schema level)
.'objtype' is the actual type which can be OBJECT_SEQUENCE or OBJECT_TABLE or
... . I think if we follow this way, the code could be cleaner.
Second, we can move the special relation expression into a separate rule
'speical_relation_expr' like the following, this can remove duplicate code
used by pubobj_expr.
------
relation_expr:
qualified_name
{}
| speical_relation_expr
{
$$ = $1;
}
;
speical_relation_expr:
qualified_name '*'
{}
| ONLY qualified_name
{}
| ONLY '(' qualified_name ')'
{}
;
------
Finally, the gram.y will look like the following.
Personally, the code looks cleaner in this approach.
-----
pubobj_expr:
any_name
{
/* inheritance query, implicitly */
$$ = makeNode(PublicationObjSpec);
$$->targettype = TARGETOBJ_UNKNOWN;
$$->object = $1;
}
| special_relation_expr
{
$$ = makeNode(PublicationObjSpec);
$$->targettype = TARGETOBJ_TABLE;
$$->object = $1;
}
| CURRENT_SCHEMA
{
$$ = makeNode(PublicationObjSpec);
$$->object = list_make1(makeString("CURRENT_SCHEMA"));
$$->targettype = TARGETOBJ_SCHEMA;
}
;
/* FOR TABLE and FOR ALL TABLES IN SCHEMA specifications */
PublicationObjSpec: TABLE pubobj_expr
{
$$ = $2;
$$->pubobjtype = PUBLICATIONOBJ_TABLE_LIST;
$$->location = @1;
}
| ALL TABLES IN_P SCHEMA pubobj_expr
{
$$ = $5;
$$->pubobjtype = PUBLICATIONOBJ_SCHEMA_LIST;
$$->location = @1;
}
| pubobj_expr
{
$$ = $1;
$$->pubobjtype = PUBLICATIONOBJ_UNKNOWN;
$$->location = @1;
}
;
Attach a diff patch based on v26-0002 patch, which change the corresponding
code based on the design above. Please have a look.
Best regards,
Hou zj
Attachment | Content-Type | Size |
---|---|---|
0001-refactor_patch | application/octet-stream | 7.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2021-09-10 03:22:30 | Re: ExecRTCheckPerms() and many prunable partitions |
Previous Message | Bossart, Nathan | 2021-09-10 02:26:10 | Re: Estimating HugePages Requirements? |