On 2021-Sep-15, vignesh C wrote: > I have extracted the parser code and attached it here, so that it will > be easy to go through. We wanted to support the following syntax as in > [1]: > CREATE PUBLICATION pub1 FOR > TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2, > SEQUENCE seq1,seq2, ALL SEQUENCES IN SCHEMA s3,s4;
Oh, thanks, it looks like this can be useful. We can get the common grammar done and then rebase all the other patches (I was also just told about support for sequences in [1]) on top. [1] https://postgr.es/m/3d6df331-5532-6848-eb45-344b265e0...@enterprisedb.com > Columns can be added to PublicationObjSpec data structure. Right. (As a List of String, I imagine.) > 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. -- Álvaro Herrera 39°49'30"S 73°17'W — https://www.EnterpriseDB.com/
