Re: A Modest Upgrade Proposal

On 8 July 2016 at 02:41, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Thu, Jul 7, 2016 at 7:15 PM, Simon Riggs <simon(at)2ndquadrant(dot)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.

I think the problem was that I gave everybody an even shot at commenting,
rather than focusing on a few key developers.

There were twenty people actively involved in that discussion.

> > 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.

Without being in the room, its kinda hard for you to know, right?

> > 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.

I don't agree, not least because I wasn't the only one saying it.

--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services