Re: Add CREATE support to event triggers

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add CREATE support to event triggers
Date: 2014-11-08 17:30:29
Message-ID: CA+TgmobA4QNGJRra01po-VtZjHAJo26r6S3frrjMyzjuAv8xgA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Nov 8, 2014 at 12:20 PM, Andres Freund <andres(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-11-08 17:40:28 Re: row_to_json bug with index only scans: empty keys!
Previous Message Andrew Dunstan 2014-11-08 17:30:05 Re: row_to_json bug with index only scans: empty keys!