RE: Added schema level support for publication.

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

In response to

Responses

Browse pgsql-hackers by date

  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?