On Wed, 7 Apr 2021 10:50:26 -0700
Mark Dilger <mark.dilger@enterprisedb.com> wrote:
> > 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 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,
