> On Apr 7, 2021, at 12:13 PM, Alvaro Herrera <alvhe...@alvh.no-ip.org> wrote:
>
> On 2021-Apr-07, Mark Dilger wrote:
>
>> It's not sufficient to think about postgres versions as "10", "11",
>> etc. You have to be able to spin up nodes of any build, like "9.0.7".
>> There are specific versions of postgres with specific bugs that cause
>> specific problems, and later versions of postgres on that same
>> development branch have been patched. If you only ever spin up the
>> latest version, you can't reproduce the problems and test how they
>> impact cross version compatibility.
>
> I don't get it. Surely if you need 10.0.7 you just compile that version
> and give its path as install path? You can have two 1.0.x as long as
> install them separately, right?
I was commenting on the design to have the PostgresNode derived subclass
hard-coded to return "10" as the version:
sub version { return 10 }
It's hard to think about how this other system works when you have lots of
separate micro releases all compiled and used as the basis of the $node's,
since this other system does not support that at all. So maybe it can be done
properly, but I don't want to have different microversions of 10 and then find
that $a->version eq $b->version when $a is 10.1 and $b is 10.2.
>> I don't think it works to have a class per micro release.
>
> I don't understand why you would do that.
If you need a "version" subroutine per derived class, then the only way to
solve the problem is to have a profusion of derived classes. It would make
more sense to me if the version method worked the way I implemented it, where
it just returns the version obtained from pg_config
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
