Re: Column Filtering in Logical Replication
vignesh C <vignesh21@gmail.com>
On Thu, Sep 16, 2021 at 7:20 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
>
> On 2021-Sep-16, vignesh C wrote:
>
> > diff --git a/src/backend/parser/gram.y b/src/backend/parser/gram.y
> > index e3068a374e..c50bb570ea 100644
> > --- a/src/backend/parser/gram.y
> > +++ b/src/backend/parser/gram.y
>
> Yeah, on a quick glance this looks all wrong. Your PublicationObjSpec
> production should return a node with tag PublicationObjSpec, and
> pubobj_expr should not exist at all -- that stuff is just making it all
> more confusing.
>
> I think it'd be something like this:
>
> PublicationObjSpec:
> ALL TABLES
> {
> $$ = makeNode(PublicationObjSpec);
> $$->pubobjtype = PUBLICATIONOBJ_ALL_TABLES;
> $$->location = @1;
> }
> | TABLE qualified_name
> {
> $$ = makeNode(PublicationObjSpec);
> $$->pubobjtype = PUBLICATIONOBJ_TABLE;
> $$->pubobj = $2;
> $$->location = @1;
> }
> | ALL TABLES IN_P SCHEMA name
> {
> $$ = makeNode(PublicationObjSpec);
> $$->pubobjtype = PUBLICATIONOBJ_ALL_TABLES_IN_SCHEMA;
> $$->pubobj = makeRangeVar( ... $5 ... );
> $$->location = @1;
> }
> | qualified_name
> {
> $$ = makeNode(PublicationObjSpec);
> $$->pubobjtype = PUBLICATIONOBJ_CONTINUATION;
> $$->pubobj = $1;
> $$->location = @1;
> };
>
> You need a single object name under TABLE, not a list -- this was Tom's
> point about needing post-processing to determine how to assign a type to
> a object that's what I named PUBLICATIONOBJ_CONTINUATION here.
In the above, we will not be able to use qualified_name, as
qualified_name will not support the following syntaxes:
create publication pub1 for table t1 *;
create publication pub1 for table ONLY t1 *;
create publication pub1 for table ONLY (t1);
To solve this problem we can change qualified_name to relation_expr
but the problem with doing that is that the user will be able to
provide the following syntaxes:
create publication pub1 for all tables in schema sch1 *;
create publication pub1 for all tables in schema ONLY sch1 *;
create publication pub1 for all tables in schema ONLY (sch1);
To handle this we will need some special flag which will differentiate
these and throw errors at post processing time. We need to define an
expression similar to relation_expr say pub_expr which handles all
variants of qualified_name and then use a special flag so that we can
throw an error if somebody uses the above type of syntax for schema
names. And then if we have to distinguish between schema name and
relation name variant, then we need few other things.
We proposed the below solution which handles all these problems and
also used Node type which need not store schemaname in RangeVar type:
pubobj_expr:
pubobj_name
{
/* inheritance query, implicitly */
$$ = makeNode(PublicationObjSpec);
$$->object = $1;
}
| extended_relation_expr
{
$$ = makeNode(PublicationObjSpec);
$$->object = (Node *)$1;
}
| CURRENT_SCHEMA
{
$$ = makeNode(PublicationObjSpec);
$$->object = (Node
*)makeString("CURRENT_SCHEMA");
}
;
/* This can be either a schema or relation name. */
pubobj_name:
ColId
{
$$ = (Node *) makeString($1);
}
| ColId indirection
{
$$ = (Node *)
makeRangeVarFromQualifiedName($1, $2, @1, yyscanner);
}
;
/* FOR TABLE and FOR ALL TABLES IN SCHEMA specifications */
PublicationObjSpec: TABLE pubobj_expr
{
$$ = $2;
$$->pubobjtype =
PUBLICATIONOBJ_TABLE;
$$->location = @1;
}
| ALL TABLES IN_P SCHEMA pubobj_expr
{
$$ = $5;
$$->pubobjtype =
PUBLICATIONOBJ_REL_IN_SCHEMA;
$$->location = @1;
}
| pubobj_expr
{
$$ = $1;
$$->pubobjtype =
PUBLICATIONOBJ_UNKNOWN;
$$->location = @1;
}
;
The same has been proposed in the recent version of patch [1].
[1] - https://www.postgresql.org/message-id/CALDaNm0OudeDeFN7bSWPro0hgKx%3D1zPgcNFWnvU_G6w3mDPX0Q%40mail.gmail.com
Thoughts?
Regards,
Vignesh
Commits
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Doc: Explain about Column List feature.
- f98d07424523 16.0 landed
- 25996a82a446 15.0 landed
-
Doc: fix column list vs. replica identity rules.
- 376af686111e 16.0 landed
- ab3131880d8a 15.0 landed
-
Prohibit combining publications with different column lists.
- fd0b9dcebda7 15.0 cited
-
Fix the check to limit sync workers.
- be46985bed8a 10.21 landed
- a90de822e483 11.16 landed
- 59348fbdeb7b 12.11 landed
- 82d4a17a1750 13.7 landed
- c9dea58e2702 14.3 landed
- dd4ab6fd6528 15.0 landed
-
Wait for subscription to sync in t/031_column_list.sql
- 404f49338fef 15.0 landed
-
Move prattrs to the pg_publication_rel section in docs
- 41b00f8e601f 15.0 landed
-
Allow specifying column lists for logical replication
- 923def9a533a 15.0 landed
-
Fix row filters with multiple publications
- 5a079662256e 15.0 landed
-
Fix publish_as_relid with multiple publications
- 27fafee72d17 13.7 landed
- 677a1dc0ca0f 14.3 landed
- c91f71b9dc91 15.0 landed
-
Add some additional tests for row filters in logical replication.
- ceb57afd3ce1 15.0 cited
-
Add index on pg_publication_rel.prpubid
- 025b920a3d45 15.0 landed
-
Avoid using DefElemAction in AlterPublicationStmt
- 9623d8999603 15.0 landed
-
Small cleanups related to PUBLICATION framework code
- c9105dd3660f 15.0 landed
-
Add PublicationTable and PublicationRelInfo structs
- 0c6828fa987b 15.0 landed
-
Fix various concurrency issues in logical replication worker launching
- de4389712206 10.0 cited