Re: Pglogical questions and problems - Mailing list pgsql-hackers

From Joshua D. Drake
Subject Re: Pglogical questions and problems
Date
Msg-id 570FCC85.1020605@commandprompt.com
Whole thread Raw
In response to Re: Pglogical questions and problems  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On 04/14/2016 08:26 AM, Simon Riggs wrote:
> On 13 April 2016 at 17:48, Robert Haas <robertmhaas@gmail.com
> <mailto:robertmhaas@gmail.com>> wrote:
>
>     On Wed, Apr 13, 2016 at 4:38 AM, Simon Riggs <simon@2ndquadrant.com
>     <mailto:simon@2ndquadrant.com>> wrote:
>     > Anyway, who agrees with the overall design of pglogical and who does not?
>
>     I haven't spent very much time on it yet.  I tend to prefer the idea
>     of integrating it more deeply into core and adding SQL syntax around
>     it, but I'm not going to fight tooth and nail for that if a contrary
>     consensus emerges.
>
>
> 1) "more deeply into core"
> I'm open to doing that for some parts of the code, if there is benefit.
> At present, an extension has exactly the same attributes as an in-core
> solution, so I don't currently see any benefit in doing so. Could you
> explain what you see?
From my perspective, grammar.

>
> 2) "SQL syntax"
> I'm not sure what SQL syntax would give us. I know what we would lose,
> which is the ability to implement new and interesting features as
> extensions before putting them into core. That doesn't strike me as a
> benefit, so please explain.

If by SQL syntax we mean things like "ALTER TABLE ENABLE REPLICATION" 
then it is an absolute user benefit.

Sincerely,

Joshua D. Drake
-- 
Command Prompt, Inc.                  http://the.postgres.company/                        +1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.



pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: Refactor pg_dump as a library?
Next
From: Andres Freund
Date:
Subject: Re: Refactor pg_dump as a library?