Re: Add CREATE support to event triggers - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Add CREATE support to event triggers
Date
Msg-id CAB7nPqTOjLgvZ-aS3Os5WtX4d2Q5X68q5rpgiJBZidQbA9v5qw@mail.gmail.com
Whole thread Raw
In response to Re: Add CREATE support to event triggers  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Thu, Nov 27, 2014 at 10:16 AM, Bruce Momjian <bruce@momjian.us> wrote:
> On Sat, Nov  8, 2014 at 05:56:00PM +0100, Andres Freund wrote:
>> On 2014-11-08 11:52:43 -0500, Tom Lane wrote:
>> > Adding a similar
>> > level of burden to support a feature with a narrow use-case seems like
>> > a nonstarter from here.
>>
>> I don't understand this statement. In my experience the lack of a usable
>> replication solution that allows temporary tables and major version
>> differences is one of the most, if not *the* most, frequent criticisms
>> of postgres I hear. How is this a narrow use case?
>
> How would replicating DDL handle cases where the master and slave
> servers have different major versions and the DDL is only supported by
> the Postgres version on the master server?  If it would fail, does this
> limit the idea that logical replication allows major version-different
> replication?
Marking this patch as "Returned with feedback". Even with the
more-fundamental arguments of putting such replication solution
in-core or not (I am skeptical as well btw), on a
code-base-discussion-only I don't think that this patch is acceptable
as-is without more structure of jsonb to do on-memory manipulation of
containers (aka remove ObjTree stuff).
Regards,
-- 
Michael



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: gist vacuum gist access
Next
From: Michael Paquier
Date:
Subject: Re: Selectivity estimation for inet operators