From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Jehan-Guillaume de Rorthais <jgdr(at)dalibo(dot)com> |
Cc: | Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: multi-install PostgresNode fails with older postgres versions |
Date: | 2021-04-07 17:36:31 |
Message-ID: | 20210407173631.GA10557@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2021-Apr-07, Jehan-Guillaume de Rorthais 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.
> Let me know if it worth that I work on an official patch.
Let's give it a try ...
--
Álvaro Herrera Valdivia, Chile
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2021-04-07 17:38:39 | Re: multi-install PostgresNode fails with older postgres versions |
Previous Message | Jehan-Guillaume de Rorthais | 2021-04-07 17:19:21 | Re: multi-install PostgresNode fails with older postgres versions |