Re: Event Triggers: adding information
От | Robert Haas |
---|---|
Тема | Re: Event Triggers: adding information |
Дата | |
Msg-id | CA+TgmobzEa+=2ufCJ-7SZBaRV_TSGZq2tKz0W4MdGpU=cLH2JQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Event Triggers: adding information (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Event Triggers: adding information
|
Список | pgsql-hackers |
On Fri, Jan 18, 2013 at 5:12 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Fri, Jan 18, 2013 at 1:59 PM, Tom Lane <tgl@sss.pgh.pa.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
В списке pgsql-hackers по дате отправления: