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 1n1W5P-0001GV-QG for pgsql-hackers@arkaria.postgresql.org; Sun, 26 Dec 2021 16:09:27 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1n1W5O-00011y-8B for pgsql-hackers@arkaria.postgresql.org; Sun, 26 Dec 2021 16:09:26 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n1W5N-00011p-UO for pgsql-hackers@lists.postgresql.org; Sun, 26 Dec 2021 16:09:25 +0000 Received: from new3-smtp.messagingengine.com ([66.111.4.229]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n1W5L-0002MP-Ps for pgsql-hackers@lists.postgresql.org; Sun, 26 Dec 2021 16:09:24 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailnew.nyi.internal (Postfix) with ESMTP id C9F88580179; Sun, 26 Dec 2021 11:09:22 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Sun, 26 Dec 2021 11:09:22 -0500 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= fm1; bh=I1ysLb+MnjN9+o9htGfBB6MAbqyYatOxOL2Rrq8tcvE=; b=d/EFqudR gqCeZ0OClrN48WIFfIIdY4pEHYrY9RjwlpyRUfaXVb1/8caFyJch8qhxDfRbE+Cs FH4tzlGeo/qEHRgn4/nSASqKVRwnlZUTLf0Fmp55L/ogL3NRe/8Fj6HpWnLD/LDz Ojcto4w3M3+pvsUaB6Kw0KOQtE2IMRNCjFWmGxwuGi0x25caUZbLiat7jl4c4dqv uIEWO7gt+XA8ZEtp4dJWV+r1ATV4esEHY0hlynDW8IjcoaUmxKYAlqgDER7ZBuK7 HjjLZVplZv7ZahzSQPNxRfD/zuskyhOxf3Ayp7tW/FGPQumeodsqTUL8I/3vXKIe nhoe6r8k4o67yg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddruddugedgheefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfggtggugfgjsehtkeertddttdejnecuhfhrohhmpeetlhhvrghr ohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhgqe enucggtffrrghtthgvrhhnpedujeevjeffjeevuddutedvkeeiueeitddvieelfeekveej udefgeeuvdejhfeuleenucffohhmrghinhepvghnthgvrhhprhhishgvuggsrdgtohhmne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghlvhhh vghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 26 Dec 2021 11:09:21 -0500 (EST) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 24CD32A0514; Sun, 26 Dec 2021 13:09:18 -0300 (-03) Date: Sun, 26 Dec 2021 13:09:18 -0300 From: Alvaro Herrera To: Euler Taveira Cc: Amit Kapila , Peter Smith , Ajin Cherian , "houzj.fnst@fujitsu.com" , Greg Nancarrow , vignesh C , "tanghy.fnst@fujitsu.com" , Dilip Kumar , Rahila Syed , Peter Eisentraut , =?utf-8?B?w5ZuZGVyIEthbGFjxLE=?= , japin , Michael Paquier , David Steele , Craig Ringer , Amit Langote , PostgreSQL Hackers Subject: Re: row filtering for logical replication Message-ID: <202112261609.qp3j4dz2ha2b@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4571f556-0209-495a-8eed-89367ae09a2a@www.fastmail.com> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2021-Dec-26, Euler Taveira wrote: > On Sat, Dec 25, 2021, at 1:20 AM, Amit Kapila wrote: > > On Fri, Dec 24, 2021 at 11:04 AM Peter Smith wrote: > > > > > > So, IMO the PG docs wording for this part should be relaxed a bit. > > > > > > e.g. > > > BEFORE: > > > + A nullable column in the WHERE clause could cause the > > > + expression to evaluate to false; avoid using columns without not-null > > > + constraints in the WHERE clause. > > > AFTER: > > > + A nullable column in the WHERE clause could cause the > > > + expression to evaluate to false. To avoid unexpected results, any possible > > > + null values should be accounted for. Is this actually correct? I think a null value would cause the expression to evaluate to null, not false; the issue is that the filter considers a null value as not matching (right?). Maybe it's better to spell that out explicitly; both these wordings seem distracting. You have this elsewhere: + If the optional WHERE clause is specified, only rows + that satisfy the expression + will be published. Note that parentheses are required around the + expression. It has no effect on TRUNCATE commands. Maybe this whole thing is clearer if you just say "If the optional WHERE clause is specified, rows for which the expression returns false or null will not be published." With that it should be fairly clear what happens if you have NULL values in the columns used in the expression, and you can just delete that phrase you're discussing. -- Álvaro Herrera Valdivia, Chile — https://www.EnterpriseDB.com/