Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1erQmm-0002Zc-LR for pgsql-hackers@arkaria.postgresql.org; Thu, 01 Mar 2018 16:10:24 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1erQmk-0006CT-3U for pgsql-hackers@arkaria.postgresql.org; Thu, 01 Mar 2018 16:10:22 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1erQjL-0000AS-SV for pgsql-hackers@lists.postgresql.org; Thu, 01 Mar 2018 16:06:52 +0000 Received: from xvm-110-146.dc2.ghst.net ([46.226.110.146] helo=fetter.org) by magus.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1erQjE-00043z-2o for pgsql-hackers@postgresql.org; Thu, 01 Mar 2018 16:06:50 +0000 Received: by fetter.org (Postfix, from userid 1001) id CF0D740105; Thu, 1 Mar 2018 17:06:42 +0100 (CET) Date: Thu, 1 Mar 2018 17:06:42 +0100 From: David Fetter To: Euler Taveira Cc: pgsql-hackers Subject: Re: row filtering for logical replication Message-ID: <20180301160642.GH25493@fetter.org> References: <20180301004752.GG25493@fetter.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Thu, Mar 01, 2018 at 12:41:04PM -0300, Euler Taveira wrote: > 2018-02-28 21:47 GMT-03:00 David Fetter : > > I noticed that the WHERE clause applies to all tables in the > > publication. Is that actually the right thing? I'm thinking of a > > case where we have foo(id, ...) and bar(foo_id, ....). To slice that > > correctly, we'd want to do the ids in the foo table and the foo_ids in > > the bar table. In the system as written, that would entail, at least > > potentially, writing a lot of publications by hand. > > > I didn't make it clear in my previous email and I think you misread > the attached docs. Each table can have an optional WHERE clause. I'll > made it clear when I rewrite the tests. Something like: Sorry I misunderstood. > CREATE PUBLICATION tap_pub FOR TABLE tab_rowfilter_1 WHERE (a > 1000 > AND b <> 'filtered'), tab_rowfilter_2 WHERE (c % 2 = 0), > tab_rowfilter_3; That's great! > Such syntax will not block another future feature that will publish > only few columns of the table. > > > I also noticed that in psql, \dRp+ doesn't show the WHERE clause, > > which it probably should. > > > Yea, it could be added be I'm afraid of such long WHERE clauses. I think of + as signifying, "I am ready to get a LOT of output in order to see more detail." Perhaps that's just me. > > Does it need regression tests? > > > I included some tests just to demonstrate the feature but I'm > planning to add a separate test file for it. Excellent. This feature looks like a nice big chunk of the user-space infrastructure needed for sharding, among other things. Best, David. -- David Fetter http://fetter.org/ Phone: +1 415 235 3778 Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate