Re: Built-in plugin for logical decoding output

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>, Alvaro Hernandez <aht(at)ongres(dot)com>, Euler Taveira <euler(at)timbira(dot)com(dot)br>, Gregory Brail <gregbrail(at)google(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Built-in plugin for logical decoding output
Date: 2017-09-25 17:50:29
Message-ID: 20381.1506361829@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)de> writes:
>> On 25/09/17 19:26, Tom Lane wrote:
>>> The problem with this type of argument is that it leads directly to the
>>> conclusion that every feature users want must be in core.

> ... I don't think that should mean that there's no possible output
> plugin that could/should be integrated into core.

Yeah, my point is just that the argument needs to be about why a
*particular* plugin is valuable enough to justify adding it to the
core developers' maintenance workload.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2017-09-25 17:52:48 Re: Reading backup label file for checkpoint and redo location during crash recovery
Previous Message Maksim Milyutin 2017-09-25 17:50:28 [BUG] Cache invalidation for queries that contains const of temporary composite type