Re: multi-install PostgresNode fails with older postgres versions - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: multi-install PostgresNode fails with older postgres versions
Date
Msg-id f35ee438-623e-9889-050a-56537c2bd57b@dunslane.net
Whole thread Raw
In response to Re: multi-install PostgresNode fails with older postgres versions  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: multi-install PostgresNode fails with older postgres versions  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
On 4/7/21 4:19 PM, Alvaro Herrera wrote:
> On 2021-Apr-07, Andrew Dunstan wrote:
>
>> b) as it stands pgaTester.pm can't be used for multiple versions in a
>> single program, which is a design goal here - it sets the single class
>> to invoke in its BEGIN block. At the very least we would need to replace
>> that with code which would require the relevant class as needed.
> I'm not suggesting that we adopt pgaTester.pm!  I think a real patch for
> this approach involves moving that stuff into PostgresNode::new itself,
> as I said upthread: if install_path is given, call pg_config --version
> and then parse the version number into a class name $versionclass, then
> "bless $versionclass, $self".  So the object returned by
> PostgresNode::new already has the correct class.  We don't need to
> require anything, since all classes are in the same PostgresNode.pm
> file.
>


Oh, you want to roll them all up into one file? That could work. It's a
bit frowned on by perl purists, but I've done similar (see PGBuild/SCM.pm).


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com




pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Minimal logical decoding on standbys
Next
From: Mark Dilger
Date:
Subject: Re: multi-install PostgresNode fails with older postgres versions