RE: Column Filtering in Logical Replication

From: "houzj(dot)fnst(at)fujitsu(dot)com" <houzj(dot)fnst(at)fujitsu(dot)com>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: vignesh C <vignesh21(at)gmail(dot)com>, Rahila Syed <rahilasyed90(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Subject: RE: Column Filtering in Logical Replication
Date: 2021-09-25 01:54:12
Message-ID: OS0PR01MB571617A4C02658FE0767ABE494A59@OS0PR01MB5716.jpnprd01.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

From Fri, Sep 24, 2021 9:25 PM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2021-09-25 02:44:15 Re: decoupling table and index vacuum
Previous Message Peter Geoghegan 2021-09-25 01:17:21 Re: decoupling table and index vacuum