A heap rewrite during a DDL command publishes changes for relations named like pg_temp_%u, which are not real tables, and this breaks replication systems that are not aware of that. We have a hack in the pgoutput plugin to ignore those, but we knew that was a hack. So here is an attempt at a more proper solution: Store a relisrewrite column in pg_class and filter on that.
I have put this into reorderbuffer.c, so that it affects all plugins. An alternative would be to have each plugin handle it separately (the way it is done now), but it's hard to see why a plugin would not want this fixed behavior.
A more fancy solution would be to make this column an OID that links back to the original table. Then, a DDL-aware plugin could choose replicate the rewrite rows. However, at the moment no plugin works that way, so this might be overdoing it.
I'm pretty sure we _will_ want the ability to decode and stream rewrite contents for non-IMMUTABLE table rewrites.
Filtering out by default is OK by me, but I think making it impossible to decode is a mistake. So I'm all for the oid option and had written a suggestion for it before I saw you already mentioned it in the next part of your mail.
The main issue with filtering out rewrites by default is that I don't see how, if we default to ignore/filter-out, plugins would indicate "actually I want to choose about this one" or "I understand table rewrites". I'd prefer not to add another change callback.
