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

From Andres Freund
Subject Re: Add CREATE support to event triggers
Date
Msg-id 20141108172005.GA4826@alap3.anarazel.de
Whole thread Raw
In response to Re: Add CREATE support to event triggers  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Add CREATE support to event triggers  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 2014-11-08 12:07:41 -0500, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > 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?
> 
> [ shrug... ]  I don't personally give a damn about logical replication,
> especially not logical replication implemented in this fashion.

"In this fashion" meaning ddl replication via event triggers? If you
have an actual suggestion how to do it better I'm all ears. So far
nobody has come up with anything.

> Or in short: AFAICS you're not building the next WAL-shipping replication
> solution, you're building the next Slony, and Slony never has and never
> will be more than a niche use-case.

A good number of the sites out there use either londiste or slony. Not
because they like it, but because there's no other alternative.

I'd love to simply say that we can make WAL based replication work
across versions, platforms and subsets of relations in PG
clusters. Since that seems quite unrealistic people have to go different
ways.

> 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.

> Core developers are entitled to push back on such proposals.

I'm not saying "core developers" (whover that is) aren't allowed to do
so. But just because they think something is (too) invasive doesn't make
it a niche application.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: row_to_json bug with index only scans: empty keys!
Next
From: Kevin Grittner
Date:
Subject: Re: row_to_json bug with index only scans: empty keys!