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. > 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. > There are already many successful features that don't utilize DDL, such as > backup, advisory locks and some features that use DDL that don't really need > to such as LISTEN/NOTIFY, full text search etc.. Also note that both Oracle > and SQLServer have moved away from DDL in favour of function APIs, most > NoSQL databases and almost all languages prefer functional interfaces over > parsed text languages, so I don't see a huge industry revival for DDL as > means of specifying things. DDL is our standard way of getting things into the system catalogs. We have no system catalog metadata that is intended to be populated by any means other than DDL. If you want to add a column to a table, you say ALTER TABLE .. ADD COLUMN. If you want to add a column to an extension, you say ALTER EXTENSION .. ADD TABLE. If you want to add an option to a foreign table, you say ALTER FOREIGN TABLE .. OPTIONS (ADD ..). Therefore, I think it is entirely reasonable and obviously consistent with existing practice that if you want to add a table to a replication set, you should write ALTER REPLICATION SET .. ADD TABLE. I don't understand why logical replication should be the one feature that departs from the way that all of our other features work. Sure, we have other features that do not involve DDL, but (1) one of your examples is full text search, which of course does have DDL, and was moved from an interface that did not involve DDL to one that did because the latter is better and (2) your other examples don't involve defining catalog contents, which makes them apples-to-oranges comparisons. 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
