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-344b265e0238@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/
