Enhancement idea - supporting Eventually Consistent requirements in same DB

[emrul]

Hi,

First off, thank you for working on such a great extension to Postgres. Looking over at an overview of it http://bonesmoses.org/2016/10/14/pg-phriday-perfectly-logical/ we see this comment:

if I wanted to make an eventually consistent ‘view’ table that stored things like aggregations, etc. could I (and should I..) create a logical replication slot back into the same DB? Essentially, trying to recreate functionality that an asynchronous trigger might give us.

And this reply:

You probably can, but not with pglogical. So far as I can tell, the table names in the provider and subscriber have to match. So if you somehow managed to get a pglogical node to subscribe to itself for the same subscription set, you’d just end up with a geometric recursive loop. You couldn’t get the inserts redirected into another table within the same database. That’s a cool idea, though. I wonder if they would add recipient table name as an option somewhere.

So opening an issue here so it can be kept track of since I think that can be a useful enhancement. In our particular case, we keep track of multiple hierarchies (paths) and currently they're kept updated using triggers BUT there's no need to keep them up-to-date within insert/update transactions. It'd be great if we could run them on some kind of background job which this type of improvement would give us.

[PJMODOS]

Yes this would be nice to have, but we don't have any immediate plans for adding it.