]> git.ipfire.org Git - thirdparty/postgresql.git/commit
Split vacuumdb to create vacuuming.c/h
authorÁlvaro Herrera <alvherre@kurilemu.de>
Fri, 26 Sep 2025 14:21:28 +0000 (16:21 +0200)
committerÁlvaro Herrera <alvherre@kurilemu.de>
Fri, 26 Sep 2025 14:21:28 +0000 (16:21 +0200)
commitc4067383cb2c155c4cfea2351036709e2ebb3535
treea67bccf518b9d4cbce6f43f63c8e7b5ea10b7663
parentdbf8cfb4f02eb9ec5525de1761675f9babfd30e3
Split vacuumdb to create vacuuming.c/h

This allows these routines to be reused by a future utility heavily
based on vacuumdb.

I made a few relatively minor changes from the original, most notably:

- objfilter was declared as an enum but the values are bit-or'ed, and
  individual bits are tested throughout the code.  We've discussed this
  coding pattern in other contexts and stayed away from it, on the
  grounds that the values so generated aren't really true values of the
  enum.  This commit changes it to be a bits32 with a few #defines for
  the flag definitions, the way we do elsewhere.  Also, instead of being
  a global variable, it's now in the vacuumingOptions struct.

- Two booleans, analyze_only (in vacuumingOptions) and analyze_in_stages
  (passed around as a separate boolean argument), are really determining
  what "mode" the program runs in -- it's either vacuum, or one of those
  two modes.  I have three adjectives for them: inconsistent,
  unergonomic, unorthodox.  Removing these and replacing them with a
  mode enum to be kept in vacuumingOptions makes the code structure easier
  to understand in a couple of places, and it'll be useful for the new
  mode we add next, so do that.

Reviewed-by: Antonin Houska <ah@cybertec.at>
Discussion: https://postgr.es/m/202508301750.cbohxyy2pcce@alvherre.pgsql
src/bin/scripts/Makefile
src/bin/scripts/meson.build
src/bin/scripts/nls.mk
src/bin/scripts/vacuumdb.c
src/bin/scripts/vacuuming.c [new file with mode: 0644]
src/bin/scripts/vacuuming.h [new file with mode: 0644]
src/tools/pgindent/typedefs.list