Re: Column Filtering in Logical Replication

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: vignesh C <vignesh21(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, 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>
Subject: Re: Column Filtering in Logical Replication
Date: 2021-09-23 10:18:57
Message-ID: CAA4eK1J5siLhZch1fwUjmEhL3q_cVS66dH3s1kXWuwPie8rwAw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Sep 17, 2021 at 9:36 AM vignesh C <vignesh21(at)gmail(dot)com> wrote:
>
> On Thu, Sep 16, 2021 at 7:20 PM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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:
>

Alvaro, do you have any thoughts on these proposed grammar changes?

--
With Regards,
Amit Kapila.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Marcos Pegoraro 2021-09-23 10:22:59 Re: logical replication restrictions
Previous Message Joe Wildish 2021-09-23 09:33:32 Re: [PATCH] Allow queries in WHEN expression of FOR EACH STATEMENT triggers