Tom, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost <sfr...@snowman.net> writes: > > * Craig Ringer (cr...@2ndquadrant.com) wrote: > >> At the moment that'd be 9.5, since that's where PostgresNode was > >> introduced. But if I can find the time I'd quite like to backport > >> PostgresNode to 9.4 too. > > > Makes sense to me. > > Um ... but we still have 2 live pre-9.4 branches. If your proposal > doesn't extend to back-porting all of this stuff as far as 9.2, > I don't see what this is really buying. We'd still need version cutoff > checks in the tests.
I don't believe the explicit goal of this is to remove the version checks but rather to provide improved testing coverage in our back-branches. If we have to keep a version cutoff check for that, so be it. > (If you *do* propose back-patching all this stuff as far as 9.2, I'm not > quite sure what I'd think about that. But the proposal as stated seems > like questionable half measures.) I find that to be an extremely interesting idea, for my own 2c, but I'm not sure how practical it is. Based on all of the feedback and discussion, I'm really inclined to suggest that we support an alternative testing structure to the in-repo regression suite. Such a testing structure would allow us to have, perhaps, somewhat longer running tests than what developers run typically (frankly, we already have this, but we have perversely decided that it's "ok" when it's a configure option or a #define, but seemingly not otherwise), or tests built in a framework which simply didn't exist at the time of the major release which is being tested (such as the TAP tests), but wouldn't also force the burden of supporting those tests on our packagers (which has the other advantage of avoiding pushing new requirements on those packagers, which might be quite difficult to fulfill). In the end, the experiences I've had with pg_dump of late and trying to ensure that pg_dump 9.6 is able to work all the way back to *7.0*, makes me think that this notion of putting the one-and-only real test-suite we have into the core repo almost laughable. We aren't going to back-patch things into 7.0, nor are we likely to run 7.0 across all members of the buildfarm, so how are we to test the combinations which we claim to support? On one-off builds/installs on individual developer systems with, in some cases, hacked-up versions of PG (just to get them to build!). Is that really testing what we're worried about? Perhaps in a few cases, but I've little doubt that any serious 7.0-era deployment is going to require more effort to migrate forward than running a 9.6 pg_dump against it. That does push back a bit on if we should really be trying to support such ancient versions, but I have to admit that I'm as much of a pureist as anyone in that regard and I'd really hate to drop support for those older branches too, at least for pg_dump, since that's how one moves forward. Thanks! Stephen
signature.asc
Description: Digital signature
