Re: Slight refactoring of state check in pg_upgrade check_ function - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: Slight refactoring of state check in pg_upgrade check_ function
Date
Msg-id 20220828220609.GA338976@nathanxps13
Whole thread Raw
In response to Slight refactoring of state check in pg_upgrade check_ function  (Daniel Gustafsson <daniel@yesql.se>)
Responses Re: Slight refactoring of state check in pg_upgrade check_ function
List pgsql-hackers
On Sun, Aug 28, 2022 at 10:42:24PM +0200, Daniel Gustafsson wrote:
> I noticed that the pg_upgrade check_ functions were determining failures found
> in a few different ways.  Some keep a boolen flag variable, and some (like
> check_for_incompatible_polymorphics) check the state of the script filehandle
> which is guaranteed to be set (with the error message referring to the path of
> said file).  Others like check_loadable_libraries only check the flag variable
> and fclose the handle assuming it was opened.
> 
> The attached diff changes the functions to do it consistently in one way, by
> checking the state of the filehandle.  Since we are referring to the file by
> path in the printed error message it seemed the cleanest approach, and it saves
> a few lines of code without IMO reducing readability.
> 
> There is no change in functionality, just code consistency.

The patch looks reasonable to me.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: Avoid erroring out when unable to remove or parse logical rewrite files to save checkpoint work
Next
From: David Rowley
Date:
Subject: Re: Reducing the chunk header sizes on all memory context types