Re: Event Triggers: adding information

On Fri, Jan 18, 2013 at 5:12 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Fri, Jan 18, 2013 at 1:59 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Well, that burden already exists for non-utility statements --- why
>>> should utility statements get a pass? Other than that we tend to invent
>>> new utility syntax freely, which might be a good thing to discourage
>>> anyhow.
>
>> My concerns are that (1) it will slow down the addition of new
>> features to PostgreSQL by adding yet another barrier to commit and (2)
>> it won't be get enough use or regression test coverage to be, or
>> remain, bug-free.
>
> Meh. The barriers to inventing new statements are already mighty tall.
> As for (2), I agree there's risk of bugs, but what alternative have you
> got that is likely to be less bug-prone? At least a reverse-list
> capability could be tested standalone without having to set up a logical
> replication configuration.
>
> This should not be interpreted as saying I'm gung-ho to do this, mind
> you. I'm just saying that if our intention is to support logical
> replication of all DDL operations, none of the alternatives look cheap.

Well, we agree on that, anyway. :-)

I honestly don't know what to do about this. I think you, Alvaro, and
I all have roughly the same opinion of this, which is that it doesn't
sound fun, but there's probably nothing better. So, what do we do
when a really cool potential feature (logical replication of DDL)
butts up against an expensive future maintenance requirement? I'm not
even sure what the criteria should be for making a decision on whether
it's "worth it".

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company