On Wed, 7 Apr 2021 10:50:26 -0700 Mark Dilger <mark.dil...@enterprisedb.com> wrote:
> > On Apr 7, 2021, at 10:36 AM, Alvaro Herrera <alvhe...@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 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. Agree. > 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 does that help? If you have ten > different versions of "10" in your test, they all look the same? As PostgresNode factory already checked pg_config version, it can give it as argument to the specific class constructor. We can then have eg. major_version() and version() to return the major version and full versions. Regards,
