On 8 July 2016 at 09:41, Robert Haas <robertmh...@gmail.com> wrote:
> > > 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. Replication slots? (Arguably not catalogs, I guess) Replication origins? > 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. Because unlike all the other features, it can work usefully *across versions*. We have no extension points for DDL. For function interfaces, we do. That, alone, makes a function based interface overwhelmingly compelling unless there are specific things we *cannot reasonably do* without DDL. > 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. > Well, replication slots and replication origins aren't handled by pg_dump (or pg_basebackup). So not quite. Nor, for that matter, is streaming physical replication handled by pg_dumpall. What makes this different? That said, with pg_dump, the question to me isn't one of "support vs don't support", it's how it should work and look. In many cases it's actively undesirable to dump and restore logical replication state. Most, I'd say. There probably are cases where it's desirable to retain logical replication state such that restoring a dump resumes replication, but I challenge you to come up with any sensible and sane way that can actually be implemented. Especially since you must obviously consider the possibility of both upstream and downstream being restored from dumps. IMO the problem mostly devolves to making sure dumps taken of different DBs are consistent so new replication sessions can be established safely. And really, I think it's a separate feature to logical replication its self. To what extent are you approaching this from the PoV of wanting to use this in FDW sharding? It's unclear what vision for users you have behind the things you say must be done, and I'd like to try to move to more concrete ground. You want DDL? OK, what should it look like? What does it add over a function based interface? What's cluster-wide and what's DB-local? etc. FWIW, Petr is working on some code in the area, but I don't know how far along the work is. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
