RE: Added schema level support for publication.

Поиск
Список
Период
Сортировка
От houzj.fnst@fujitsu.com
Тема RE: Added schema level support for publication.
Дата
Msg-id OS0PR01MB5716F72CE944E386C4C75F0C94D69@OS0PR01MB5716.jpnprd01.prod.outlook.com
обсуждение исходный текст
Ответ на Re: Added schema level support for publication.  (vignesh C <vignesh21@gmail.com>)
Ответы RE: Added schema level support for publication.  ("houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>)
Список pgsql-hackers
From Wed, Sept 8, 2021 7:44 PM vignesh C <vignesh21@gmail.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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Bossart, Nathan"
Дата:
Сообщение: Re: Estimating HugePages Requirements?
Следующее
От: Amit Langote
Дата:
Сообщение: Re: ExecRTCheckPerms() and many prunable partitions