Hi, On 2019-09-04 09:41:43 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > On 2019-08-30 12:35:09 -0400, Tom Lane wrote: > >> I think it's the sort of thing that we sometimes cover in the > >> "source code" changes of the release notes. But yeah, 09568ec3d's > >> idea was pretty much fully superseded by a6417078c, so if we're > >> going to document anything it should be the latter not the former. > > > Hm - not sure I see how a6417078c supersedes 09568ec3d, on the rationale > > that we'd discussed in the thread, which the commit message sums up as: > > Add a note suggesting that oids in forks should be assigned in the > > 9000-9999 range. > > As forks != extensions, the release note entry seems misleading, and > > a6417078c doesn't seem relevant? > > If we were trying to honor that rule, we'd be asking patches to use > temporary OIDs that don't fall into the 9K range. Otherwise, a fork > that thinks it has private OIDs up there is going to have intermittent > trouble tracking HEAD.
Given the timeline 09568ec3d really couldn't forsee a6417078c... > As things stand after a6417078c, the safest place for a fork to put > private OIDs is actually from 7999 down; patches shouldn't touch that > range, and it'll be a long time till we hit it working up. Should we just update the comment to reference that then? Greetings, Andres Freund
