Slight refactoring of state check in pg_upgrade check_ function

Started by Daniel Gustafssonover 3 years ago4 messageshackers
Jump to latest
#1Daniel Gustafsson
daniel@yesql.se

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.

--
Daniel Gustafsson https://vmware.com/

Attachments:

v1-0001-Refactor-check_-functions-to-use-filehandle-for-s.patchapplication/octet-stream; name=v1-0001-Refactor-check_-functions-to-use-filehandle-for-s.patch; x-unix-mode=0644Download+7-35
#2Nathan Bossart
nathandbossart@gmail.com
In reply to: Daniel Gustafsson (#1)
Re: Slight refactoring of state check in pg_upgrade check_ function

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

#3Bruce Momjian
bruce@momjian.us
In reply to: Nathan Bossart (#2)
Re: Slight refactoring of state check in pg_upgrade check_ function

On Sun, Aug 28, 2022 at 03:06:09PM -0700, Nathan Bossart wrote:

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.

+1. Those checks have accumulated over time with different authors,
hence the stylistic differences.

--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com

Indecision is a decision. Inaction is an action. Mark Batterson

#4Daniel Gustafsson
daniel@yesql.se
In reply to: Bruce Momjian (#3)
Re: Slight refactoring of state check in pg_upgrade check_ function

On 30 Aug 2022, at 23:08, Bruce Momjian <bruce@momjian.us> wrote:
On Sun, Aug 28, 2022 at 03:06:09PM -0700, Nathan Bossart wrote:

The patch looks reasonable to me.

+1. Those checks have accumulated over time with different authors,
hence the stylistic differences.

Pushed, thanks for review!

--
Daniel Gustafsson https://vmware.com/