> On Apr 7, 2021, at 10:36 AM, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
>
>> Yes, it would be much saner to make PostgresNode the factory class. Plus, some
>> more logic could be injected there to either auto-detect the version (current
>> behavior) or eg. use a given path to the binaries as Mark did in its patch.
>
> I'm not sure what you mean about auto-detecting the version -- I assume
> we would auto-detect the version by calling pg_config from the
> configured path and parsing the binary, which is what Mark's patch is
> supposed to do already. So I don't see what the distinction between
> those two things is.
>
> In order to avoid having an ever-growing plethora of 100-byte .pm files,
> we can put the version-specific classes in the same PostgresNode.pm
> file, at the bottom, "class PostgresNode96; use parent PostgresNode10;"
> followed by the routines that are overridden for each version.
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
versionsof postgres on that same development branch have been patched. If you only ever spin up the latest version,
youcan't reproduce the problems and test how they impact cross version compatibility.
I don't think it works to have a class per micro release. So you'd have a PostgresNode of type "10" or such, but how
doesthat help? If you have ten different versions of "10" in your test, they all look the same?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
