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
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 |