Re: A Modest Upgrade Proposal

On Thu, Jul 7, 2016 at 7:15 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> Yes, I ran the unconference session. It was a shame you weren't able to stay
> for the whole discussion.

I thought I sat through, at least, most of it, but you barely gave
anyone else a chance to talk, which kind of misses the point of an
unconference.  The portion which I attended was not about how to move
the development of the feature forward, but just involved describing
it.  I thought it was a shame that the time wasn't used better.

> We all agreed that an in-core solution was desirable, if only for wider
> adoption.

Yep.

> About half the people wanted DDL and about half the people didn't. When we
> discussed why we wanted DDL there wasn't any answers apart from the thought
> that we want to be able to backup the replication configurations, which
> seemed to be possible with or without DDL. Any such backup would need to be
> easily removed from the objects themselves, to avoid external dependencies
> on making recovery work.

I really don't think that's accurate.  There might have been 50% of
people who thought that not having DDL was acceptable, but I think
there were very few people who found it preferable.

> Chris Browne finally summed it up by saying we could wait on having DDL
> until some time later, once we've decided on things like how we configure
> it, how we secure it and what/how to store it in the catalog. "We could
> probably live without DDL in the first version."

Right.  In other words, DDL would be desirable, but he'd be willing to
live without it if that somehow made things easier.  But it really
doesn't.  Adding new DDL commands is not particularly difficult.

> Personally, I'm in the group of people that don't see the need for DDL.

The burden of proof isn't on me to demonstrate why this feature "needs
DDL"; it's on you to explain why replication-related operations that
establish persistent database state don't need to behave just like all
other commands.  Really, where this jumped the shark for me is when
you argued that this stuff didn't even need pg_dump support.  Come on.
This feature doesn't get a pass from handling all of the things that
every existing similar feature needs to deal with.