RE: Column Filtering in Logical Replication - Mailing list pgsql-hackers

From houzj.fnst@fujitsu.com
Subject RE: Column Filtering in Logical Replication
Date
Msg-id OS0PR01MB571617A4C02658FE0767ABE494A59@OS0PR01MB5716.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: Column Filtering in Logical Replication  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
From Fri, Sep 24, 2021 9:25 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> On 2021-Sep-23, Amit Kapila wrote:
> 
> > Alvaro, do you have any thoughts on these proposed grammar changes?
> 
> Yeah, I think pubobj_name remains a problem in that you don't know its return
> type -- could be a String or a RangeVar, and the user of that production can't
> distinguish.  So you're still (unnecessarily, IMV) stashing an object of
> undetermined type into ->object.
> 
> I think you should get rid of both pubobj_name and pubobj_expr and do
> somethine like this:
> PublicationObjSpec:    TABLE ColId
>                     {
>                         $$ = makeNode(PublicationObjSpec);
>                         $$->pubobjtype = PUBLICATIONOBJ_TABLE;
>                         $$->rangevar = makeRangeVarFromQualifiedName($1, NULL, @1, yyscanner);
>                     }
>             | TABLE ColId indirection
>                     {
>                         $$ = makeNode(PublicationObjSpec);
>                         $$->pubobjtype = PUBLICATIONOBJ_TABLE;
>                         $$->rangevar = makeRangeVarFromQualifiedName($1, $2, @1, yyscanner);
>                     }

Hi,

IIRC, the above grammar doesn't support extended relation expression (like:
"tablename * ", "ONLY tablename", "ONLY '( tablename )") which is part of rule
relation_expr. I think we should add these too. And if we move forward with the
design you proposed, we should do something like the following:

/* FOR TABLE and FOR ALL TABLES IN SCHEMA specifications */
PublicationObjSpec:
            TABLE relation_expr
                            {
                                $$ = makeNode(PublicationObjSpec);
                                $$->pubobjtype = PUBLICATIONOBJ_TABLE;
                                $$->rangevar = $2;
                            }
            | ALL TABLES IN_P SCHEMA ColId
                            {
                                $$ = makeNode(PublicationObjSpec);
                                $$->pubobjtype = PUBLICATIONOBJ_REL_IN_SCHEMA;
                                $$->name = $5;
                            }
            | ALL TABLES IN_P SCHEMA CURRENT_SCHEMA
                            {
                                $$ = makeNode(PublicationObjSpec);
                                $$->pubobjtype = PUBLICATIONOBJ_CURRSCHEMA;
                                $$->name = $5;
                            }
            | extended_relation_expr    /* grammar like tablename * , ONLY tablename, ONLY ( tablename )*/
                            {
                                $$ = makeNode(PublicationObjSpec);
                                $$->rangevar = makeRangeVarFromQualifiedName($1, $2, @1, yyscanner);
                                $$->pubobjtype = PUBLICATIONOBJ_CONTINUATION;
                            }
            | ColId
                            {
                                $$ = makeNode(PublicationObjSpec);
                                $$->name = $1;
                                $$->pubobjtype = PUBLICATIONOBJ_CONTINUATION;

                            }
            | ColId indirection
                            {
                                $$ = makeNode(PublicationObjSpec);
                                $$->rangevar = makeRangeVarFromQualifiedName($1, $2, @1, yyscanner);
                                $$->pubobjtype = PUBLICATIONOBJ_CONTINUATION;

                            }

Best regards,
Hou zj

pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: decoupling table and index vacuum
Next
From: Peter Geoghegan
Date:
Subject: Re: decoupling table and index vacuum