Re: [HACKERS] Built-in plugin for logical decoding output

Поиск
Список
Период
Сортировка
От Craig Ringer
Тема Re: [HACKERS] Built-in plugin for logical decoding output
Дата
Msg-id CAMsr+YHoKojXw+4Sg7c76HNmAXc0Fr8Jf2kSYvo2DjmwzYY=BQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Built-in plugin for logical decoding output  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On 26 September 2017 at 01:53, Andres Freund <andres@anarazel.de> wrote:
On 2017-09-25 13:50:29 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.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.

+1


Yep, and that goes for plugins like pglogical too.

I agree we need a json plugin, it's pretty clear that's a widespread need.

But I don't buy the whole argument about "hosted postgres" issues. The hosted solutions suppliers can simply use 3rd party plugins, like some do PostGIS already. Trying to push things into core is offloading work onto us to make their lives easier and I don't much care for that.

Personally I'd be more friendly toward Amazon / Google / etc wanting us to include things for their convenience if they actually usefully contributed to development and maintenance of Pg.

--
 Craig Ringer

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: [HACKERS] Setting pd_lower in GIN metapage
Следующее
От: Craig Ringer
Дата:
Сообщение: Re: [HACKERS] Built-in plugin for logical decoding output