On Sat, Nov 8, 2014 at 12:20 PM, Andres Freund <and...@2ndquadrant.com> wrote: >> Putting half of it into core wouldn't fix that, it would just put a >> lot more maintenance burden on core developers. > > Imo stuff that can't be done sanely outside core needs to be put into > core if it's actually desired by many users. And working DDL replication > for logical replication solutions surely is.
I don't buy it. This patch series is *all about* transferring the maintenance burden of this feature from the BDR developers to the core project. There's nothing to keep you from exposing the parse trees to C functions that can live in an extension, and you can do all of this deparsing there. Nobody will stop you, and when it breaks (not if) you can fix it in your code. The overhead of deparsing new types of parse nodes can be born by you. The only benefit of pushing it into core is that some other logical replication solution could also take advantage of that, but I know of nobody with any plans to do such a thing. On the flip side, the *cost* of pushing it into core is that it now becomes the PostgreSQL's community problem to update the deparsing code every time the grammar changes. That cost-benefit trade-off does not look favorable to me, especially given the absence of any kind of robust testing framework. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers