Re: Column Filtering in Logical Replication
От | vignesh C |
---|---|
Тема | Re: Column Filtering in Logical Replication |
Дата | |
Msg-id | CALDaNm0tQKwRULvZONX1yqxjJ5CFNxficsr77C062GpCcooUjA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Column Filtering in Logical Replication (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: Column Filtering in Logical Replication
|
Список | pgsql-hackers |
On Thu, Sep 16, 2021 at 8:45 AM Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Wed, Sep 15, 2021 at 6:06 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote: > > > > On 2021-Sep-15, vignesh C wrote: > > > The patch > > > Generic_object_type_parser_002_table_schema_publication.patch has the > > > changes that were used to handle the parsing. Schema and Relation both > > > are different objects, schema is of string type and relation is of > > > RangeVar type. While parsing, schema name is parsed in string format > > > and relation is parsed and converted to rangevar type, these objects > > > will be then handled accordingly during post processing. > > > > Yeah, I think it'd be cleaner if the node type has two members, something like > > this > > > > typedef struct PublicationObjSpec > > { > > NodeTag type; > > PublicationObjSpecType pubobjtype; /* type of this publication object */ > > RangeVar *rv; /* if a table */ > > String *objname; /* if a schema */ > > int location; /* token location, or -1 if unknown */ > > } PublicationObjSpec; > > > > and only one of them is set, the other is NULL, depending on the object type. > > > > I think the problem here is that with the proposed grammar we won't be > always able to distinguish names at the gram.y stage. This is the issue that Amit was talking about: gram.y: error: shift/reduce conflicts: 2 found, 0 expected gram.y: warning: shift/reduce conflict on token ',' [-Wcounterexamples] First example: CREATE PUBLICATION name FOR TABLE relation_expr_list • ',' relation_expr ',' PublicationObjSpec opt_definition $end Shift derivation $accept ↳ parse_toplevel $end ↳ stmtmulti ↳ toplevel_stmt ↳ stmt ↳ CreatePublicationStmt ↳ CREATE PUBLICATION name FOR pub_obj_list opt_definition ↳ PublicationObjSpec ',' PublicationObjSpec ↳ TABLE relation_expr_list ↳ relation_expr_list • ',' relation_expr Second example: CREATE PUBLICATION name FOR TABLE relation_expr_list • ',' PublicationObjSpec opt_definition $end Reduce derivation $accept ↳ parse_toplevel $end ↳ stmtmulti ↳ toplevel_stmt ↳ stmt ↳ CreatePublicationStmt ↳ CREATE PUBLICATION name FOR pub_obj_list opt_definition ↳ pub_obj_list ',' PublicationObjSpec ↳ PublicationObjSpec ↳ TABLE relation_expr_list • Here it is not able to distinguish if ',' is used for the next table name or the next object. I was able to reproduce this issue with the attached patch. Regards, Vignesh
Вложения
В списке pgsql-hackers по дате отправления: