On Thu, Mar 01, 2018 at 12:41:04PM -0300, Euler Taveira wrote: > 2018-02-28 21:47 GMT-03:00 David Fetter <da...@fetter.org>: > > 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 <david(at)fetter(dot)org> http://fetter.org/ Phone: +1 415 235 3778 Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
