Re: Last gasp - Mailing list pgsql-hackers

On Thu, Apr 5, 2012 at 2:58 PM, Hannu Krosing <hannu@krosing.net> wrote:
> On Thu, 2012-04-05 at 20:46 +0200, Hannu Krosing wrote:
>> On Thu, 2012-04-05 at 14:27 -0400, Robert Haas wrote:
>> > On Thu, Apr 5, 2012 at 2:17 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>
> ...
>> > > I think doing so will cause substantial misery for many users. I find
>> > > it hard to believe that such a simple concept hasn't managed to
>> > > produce some workable subset after months of work.
>> >
>> > I am not interested in relitigating on this thread what has already
>> > been extensively discussed nearby.  Dimitri and I agreed on numerous
>> > changes to try to make the behavior sane,
>>
>> To me it looked like the scope of the patch started to suddenly expand
>> exponentially a few days ago from a simple COMMAND TRIGGERS, which would
>> have finally enabled trigger-based or "logical" replication systems to
>> do full replication to something recursive which would attempt to cover
>> all weird combinations of commands triggering other commands for which
>> there is no real use-case in view, except a suggestion "don't do it" :)
>>
>> The latest patch (v18) seemed quite ok for its original intended
>> purpose.
>
> Sorry, i hit "send!" too early.
>
> Would it be possible to put some "command trigger hooks" in a few
> strategic places so that some trigger-like functionality could be loaded
> at run time, mainly with a view of writing DDL replication
> 'non-triggers' , mostly based on current v18 code, but of course without
> all the nice CREATE TRIGGER syntax ?

I certainly think that would be a possible way forward, but I don't
think we should try to engineer that in the next 24 hours.  Had the
original goals of the patch been somewhat more modest, I think we
could have gotten it into 9.2, but there's no time to rethink the
scope of the patch now.  With all respect for Dimitri and his *very*
hard work on this subject, submitting a brand new major feature to the
last CommitFest is not really a great way to get it committed,
especially given that we didn't have consensus on the design before he
started coding.  There is every reason to think that we can get this
feature into 9.3 with some more work, but it's not ready yet, and
wishing won't make it so.

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