On 8 July 2016 at 02:41, Robert Haas <robertmh...@gmail.com> wrote: > On Thu, Jul 7, 2016 at 7:15 PM, Simon Riggs <si...@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.
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
