Re: multi-install PostgresNode fails with older postgres versions

> On Apr 7, 2021, at 12:13 PM, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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