Re: cleaning up PostgresNode.pm

On Mon, Jun 28, 2021 at 01:02:37PM -0400, Andrew Dunstan wrote:
> Patch 1 adds back the '-w' flag to pg_ctl in the start() method. It's
> redundant on modern versions of Postgres but it's harmless, and helps
> with subclassing for older versions where it wasn't the default.

05cd12e applied to all the actions, so wouldn't it be more consistent
to do the same for stop(), restart() and promote()?

> Patch 2 adds a method for altering config files as opposed to just
> appending to them. Again, this helps a lot in subclassing for older
> versions, which can call the parent's init() and then adjust whatever
> doesn't work.

+unless skip_equals is true, in which case it will write
Nit: two spaces here.

+Modify the named config file setting with the value. If the value is undefined,
+instead delete the setting. If the setting is not present no action is taken.
This should mention that parameters commented out are ignored?

skip_equals is not used. The only caller of adjust_conf is
PostgresNode itself.

> Patch 3 unifies the constructor methods and stops exporting a
> constructor. There is one constructor: PostgresNode::new()

Nice^2. I agree that this is an improvement.

> Patch 4 removes what's left of Exporter in PostgresNode, so it becomes a
> pure OO style module.

I have mixed feelings on this one, in a range of -0.1~0.1+, but please
don't consider that as a strong objection either.

> Patch 5 adds a method for getting the major version string from a
> PostgresVersion object, again useful in subclassing.

WFM.

> Patch 6 adds a method for getting the install_path of a PostgresNode
> object. While not strictly necessary it's consistent with other fields
> that have getter methods. Clients should not pry into the internals of
> objects. Experience has shown this method to be useful.

I have done that as well when looking at the test business with
pg_upgrade.

> Patches 7 8 and 9 contain additions to Patch 3 for things that I
> overlooked or that were not present when I originally prepared the
> patches. They would be applied alongside Patch 3, not separately.

That happens.

> These patches are easily broken by e.g. the addition of a new TAP test
> or the modification of an existing test. So I'm hoping to get these
> added soon. I will add this email to the CF.

I doubt that anybody would complain about any of the changes you are
doing here. It would be better to get that merged early in the
development cycle on the contrary.
--
Michael