Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mQUD2-0003yO-LI for pgsql-hackers@arkaria.postgresql.org; Wed, 15 Sep 2021 12:40:16 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mQUD1-00054i-LX for pgsql-hackers@arkaria.postgresql.org; Wed, 15 Sep 2021 12:40:15 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mQU9r-0006JI-UI for pgsql-hackers@lists.postgresql.org; Wed, 15 Sep 2021 12:36:59 +0000 Received: from out2-smtp.messagingengine.com ([66.111.4.26]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mQU9p-0008Rd-4Y for pgsql-hackers@postgresql.org; Wed, 15 Sep 2021 12:36:59 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 2F00E5C0148; Wed, 15 Sep 2021 08:36:55 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 15 Sep 2021 08:36:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=mPos0CmTiCvDHD2ST7bLK6yWXiT6ax3o0PUJ2UcvNjg=; b=wvoEx2B2 apEW6MzZVxU+CYyzMJ21zZPX6eHMhvYRrzVOHECznEHm1wZeAOrruuk4hOwr0dYZ bJ888a+iv1h6+OZxGIRPK5RtLwEH6vCeA2nyLUZv3nzocOAmG6O2o7UZpe2EQ5n0 JQa/umOR6R0cECA3cV6yuP8+OI9Y9U4hmDfG6L/ADKXYJIMeWwQknGJZomDImUA0 W/YCuJHkmrBcky48JfqKqcbiIRr0PGVunDHENTdsEM50BcjGua9yPUR//6vUQcya xBcIQxb5rgpPg8rUlj4RTTmWxGz9H/rX15/idEVaNUf1mHItesLymjeaz2sQeOdj 7v6dReYYKYuEsQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudehuddgheduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfggtggugfgjsehtkeertddttdejnecuhfhrohhmpeetlhhvrghr ohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhgqe enucggtffrrghtthgvrhhnpeejjeevffeukeejieekheehleduudehteeiudegteetkefh veelhfefvdduvdfgfeenucffohhmrghinhepphhoshhtghhrrdgvshdpvghnthgvrhhprh hishgvuggsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghi lhhfrhhomheprghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 15 Sep 2021 08:36:54 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 4D2952A0875; Wed, 15 Sep 2021 09:36:51 -0300 (-03) Date: Wed, 15 Sep 2021 09:36:51 -0300 From: Alvaro Herrera To: vignesh C Cc: Amit Kapila , Rahila Syed , Tomas Vondra , Peter Smith , PostgreSQL-development Subject: Re: Column Filtering in Logical Replication Message-ID: <202109151236.mjrtv25qamvw@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 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/