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

Поиск
Список
Период
Сортировка
От Alvaro Hernandez
Тема Re: [HACKERS] Built-in plugin for logical decoding output
Дата
Msg-id 88d9182e-e265-f840-3944-45f784779fc1@ongres.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Built-in plugin for logical decoding output  ("Joshua D. Drake" <jd@commandprompt.com>)
Ответы Re: [HACKERS] Built-in plugin for logical decoding output  ("Joshua D. Drake" <jd@commandprompt.com>)
Re: [HACKERS] Built-in plugin for logical decoding output  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers

On 25/09/17 20:31, Joshua D. Drake wrote:
> On 09/25/2017 10:19 AM, Petr Jelinek wrote:
>> On 25/09/17 18:48, Alvaro Hernandez wrote:
>>>
>
>>>      In my opinion, logical decoding plugins that don't come with core
>>> are close to worthless (don't get me wrong):
>>>
>>
>> I respectfully disagree.
>
> As do I.
    But Petr, without saying why, it does not help much to the 
discussion ;)

>
>>
>>> - They very unlikely will be installed in managed environments (an area
>>> growing significantly).
>
> Whether or not they are included in a managed environment is generally 
> based on two things:
>
>     1. Safety (why RDS doesn't allow certain C extensions)
>     2. Community/Popularity (Exactly why RDS has PostGIS)
>         A. Demand with a prerequisite of #1
    This is very clear. Now tell me: how many output plugins do you see 
included in RDS. And in GCP's PostgreSQL? Azure Postgres? Heroku?
    I'm looking at this from the practical perspective: if you would 
want to write a middleware for PostgreSQL that would rely on logical 
decoding, you definitely want to run on this platforms, or you are out 
of the game. If we want PostgreSQL to integrate more easily in nowadays 
very heterogeneous environments, this is key. And relying on 
non-included-or-acceptable-in-many environments output plugins is not, 
IMHO, a viable nor sensible option. I'd rather stick to test_decoding or 
pgoutput, no question.

>
>>> - As anything that is not in core, raises concerns by users.
>
> I find this a rather failing argument in today's market. If they are 
> willing to migrate to Postgres, they are more than likely willing to 
> use other open source software. Especially when combined with an 
> expert telling them to.
>
>
>>> - Distribution and testing are non-trivial: many OS/archs combinations.
>>>
>
> Yes, it is. Why would we want to increase that burden to this community?

    That's a different story, and one I cannot argue against. If 
easying postgresql integration with other tools is not something of a 
priority or something the core group cannot add to all the stuff on 
their shoulders, all my due respect. PostgreSQL users will do without, 
someway, somehow. But IMHO this should be a really high priority, and 
saying that this would turn PostgreSQL into an Oracle code base is going 
too far ;)

    Álvaro

-- 

Alvaro Hernandez


-----------
OnGres



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Server crash due to SIGBUS(Bus Error) when trying to access the memory created using dsm_create().
Следующее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: [HACKERS] Built-in plugin for logical decoding output