> Normally you would replicate between an older master and a newer
> replica, so this shouldn't be an issue. I find it unlikely that we
> would de-support some syntax that works in an older version: it would
> break pg_dump, for one thing.
The most common way in which we break forward-compatibility is by
reserving additional keywords. Logical replication can deal with this
by quoting all identifiers, so it's not a big issue.
It's not the only possible issue; it is certainly conceivable that we
could change something in the server and then try to change pg_dump to
compensate. I think we wouldn't do that with anything very big, but
suppose spgist were supplanted by a new and better access method
tsigps. Well, we might figure that there are few enough people
accustomed to the current syntax that we can get away with hacking the
pg_dump output, and yes, anyone with an existing dump from an older
system will have problems, but there won't be many of them, and they
can always adjust the dump by hand. If we ever decided to do such a
thing, whatever syntax transformation we did in pg_dump would have to
be mimicked by any logical replication solution.
I think it's legitimate to say that this could be a problem, but I
think it probably won't be a problem very often, and I think when it
is a problem it probably won't be a very big problem, because we
already have good reasons not to break the ability to restore older
dumps on newer servers more often than absolutely necessary.
One of the somewhat disappointing things about this is that we're
talking about adding a lot of new deparsing code to the server that
probably, in some sense, duplicates pg_dump. Perhaps in an ideal
world there would be a way to avoid that, but in the world we really
live in, there probably isn't.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
