> On Feb 24, 2019, at 14:19, Stephen Frost <sfr...@snowman.net> wrote:
> You say above that the new interface is unquestionably an improvement
> and here say that we shouldn't deprecate the old one in favor of it
> (even though we actually already have... but that's beside the point I'm
> trying to make here), so what you're advocating for is that we keep an
> old and known broken interface that we know causes real issues even
> after we've developed a new and unquestionably better one.
Yes, I am advocating exactly that. The reason that I think we need to keep the
old one (or, at least, not remove it as soon as 12) is that creating an
obstacle to upgrades is worse than retaining the old one, and it *will* be an
obstacle to upgrades (or to using the community edition at all).
I do think we need a simple, pg_basebackup-level-complexity hot backup tool
that allows a forked copy operation, per Andres' suggestion.
There's no single answer to every possible situation like this that pops up; it
depends on how widely used the interface was, how reasonable the expectation of
permanence is, and the difficulty the users will encounter in changing to the
new one, along with the complexity of maintaining the documentation and code
for the old interface.
> A lot of them depended on pg_wal being named pg_xlog too, but we seem to
> have managed reasonably well through that, not to mention all the
> catalog changes that caused issues for monitoring, etc.
Some of the incompatible catalog changes (in particular, in pg_stat_activity) I
thought were gratuitous, but we did them, and no point in relitigating that
now. I'd say that the internal layout of PGDATA is fairly weak promise
compared to an SQL-level construct, especially one as widely used as
pg_start_backup().
--
-- Christophe Pettus
x...@thebuild.com
