On Thu, Sep 04, 2014 at 09:54:37AM -0400, Robert Haas wrote:
> One point to note is that not back-patching this doesn't really fix
> anything. Will a user be annoyed when .psql_history fails to reload
> properly on a new minor release, but utterly indifferent to whether it
> reloads in a new major release?
Users won't be utterly indifferent, but they will be less alarmed. We
frequently use a major-version debut for bug fixes posing compatibility
hazards. About half the items listed in the "Migration to Version 9.4"
release notes section fit that description.
> What if they run multiple major
> releases of PostgreSQL on the same machine, using the psql executable
> for each version when talking to that version? (Yeah, I know it's
> backward compatible, but not everyone may realize that, or care.)
Sure. Had I authored the patch, I probably would have withdrawn it pending
development of a thorough plan for minimizing these problems. I don't care to
sell that level of conservatism to the rest of you. If Tom is unconcerned
about these problems and wants to move forward with the current patch for 9.5,
that works for me.
> Given that, if we're going to do it this way at all, I favor
> back-patching: at least then the newest releases of all supported
> branches will be compatible with each other.
That's a fair point. A back-patch is better for hackers, who occasionally run
each supported branch but rarely run outdated back-branch code. (When I built
PostgreSQL on OS X, I used GNU readline. I suppose some hackers do use
libedit, though.) Not sure about ordinary users, though.
> But I'm still fuzzy on
> why we need to give up the ability to read the old format in the first
> place. Can't we just fix that and be done with this?
Sort of. I see no free-lunch fix, but there are alternatives to the current
proposed patch that resolve the compromises differently.