postgresql.git/src/bin/scripts/Makefile, branch master

Update copyright for 2026

2026-01-01T18:24:10Z

Backpatch-through: 14

Split some long Makefile lists

2025-12-28T00:17:42Z

This change makes more readable code diffs when adding new items or removing old items, while ensuring that lines do not get excessively long. Some SUBDIRS, PROGRAMS and REGRESS lists are split. Note that there are a few more REGRESS lists that could be split, particularly in contrib/. Author: Jelte Fennema-Nio Co-Authored-By: Jacob Champion Reviewed-by: Chao Li Reviewed-by: Japin Li Reviewed-by: Man Zeng Discussion: https://postgr.es/m/DF6HDGB559U5.3MPRFCWPONEAE@jeltef.nl

Split vacuumdb to create vacuuming.c/h

2025-09-26T14:21:28Z

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 Discussion: https://postgr.es/m/202508301750.cbohxyy2pcce@alvherre.pgsql

Update copyright for 2025

2025-01-01T16:21:55Z

Backpatch-through: 13

Update copyright for 2024

2024-01-04T01:49:05Z

Reported-by: Michael Paquier Discussion: https://postgr.es/m/ZZKTDPxBBMt3C0J9@paquier.xyz Backpatch-through: 12

Remove distprep

2023-11-06T14:18:04Z

A PostgreSQL release tarball contains a number of prebuilt files, in particular files produced by bison, flex, perl, and well as html and man documentation. We have done this consistent with established practice at the time to not require these tools for building from a tarball. Some of these tools were hard to get, or get the right version of, from time to time, and shipping the prebuilt output was a convenience to users. Now this has at least two problems: One, we have to make the build system(s) work in two modes: Building from a git checkout and building from a tarball. This is pretty complicated, but it works so far for autoconf/make. It does not currently work for meson; you can currently only build with meson from a git checkout. Making meson builds work from a tarball seems very difficult or impossible. One particular problem is that since meson requires a separate build directory, we cannot make the build update files like gram.h in the source tree. So if you were to build from a tarball and update gram.y, you will have a gram.h in the source tree and one in the build tree, but the way things work is that the compiler will always use the one in the source tree. So you cannot, for example, make any gram.y changes when building from a tarball. This seems impossible to fix in a non-horrible way. Second, there is increased interest nowadays in precisely tracking the origin of software. We can reasonably track contributions into the git tree, and users can reasonably track the path from a tarball to packages and downloads and installs. But what happens between the git tree and the tarball is obscure and in some cases non-reproducible. The solution for both of these issues is to get rid of the step that adds prebuilt files to the tarball. The tarball now only contains what is in the git tree (*). Getting the additional build dependencies is no longer a problem nowadays, and the complications to keep these dual build modes working are significant. And of course we want to get the meson build system working universally. This commit removes the make distprep target altogether. The make dist target continues to do its job, it just doesn't call distprep anymore. (*) - The tarball also contains the INSTALL file that is built at make dist time, but not by distprep. This is unchanged for now. The make maintainer-clean target, whose job it is to remove the prebuilt files in addition to what make distclean does, is now just an alias to make distprep. (In practice, it is probably obsolete given that git clean is available.) The following programs are now hard build requirements in configure (they were already required by meson.build): - bison - flex - perl Reviewed-by: Michael Paquier Reviewed-by: Andres Freund Discussion: https://www.postgresql.org/message-id/flat/e07408d9-e5f2-d9fd-5672-f53354e9305e@eisentraut.org

Update copyright for 2023

2023-01-02T20:00:37Z

Backpatch-through: 11

Add option to use ICU as global locale provider

2022-03-17T10:13:16Z

This adds the option to use ICU as the default locale provider for either the whole cluster or a database. New options for initdb, createdb, and CREATE DATABASE are used to select this. Since some (legacy) code still uses the libc locale facilities directly, we still need to set the libc global locale settings even if ICU is otherwise selected. So pg_database now has three locale-related fields: the existing datcollate and datctype, which are always set, and a new daticulocale, which is only set if ICU is selected. A similar change is made in pg_collation for consistency, but in that case, only the libc-related fields or the ICU-related field is set, never both. Reviewed-by: Julien Rouhaud Discussion: https://www.postgresql.org/message-id/flat/5e756dd6-0e91-d778-96fd-b1bcb06c161a%402ndquadrant.com

2022-01-08T00:04:57Z

Backpatch-through: 10

Move some code from src/bin/scripts to src/fe_utils to permit reuse.

2021-02-05T18:33:38Z

The parallel slots infrastructure (which implements client-side multiplexing of server connections doing similar things, not threading or multiple processes or anything like that) are moved from src/bin/scripts/scripts_parallel.c to src/fe_utils/parallel_slot.c. The functions consumeQueryResult() and processQueryResult() which were previously part of src/bin/scripts/common.c are now moved into that file as well, becoming static helper functions. This might need to be changed in the future, but currently they're not used for anything else. Some other functions from src/bin/scripts/common.c are moved to to src/fe_utils and are split up among several files. connectDatabase(), connectMaintenanceDatabase(), and disconnectDatabase() are moved to connect_utils.c. executeQuery(), executeCommand(), and executeMaintenanceCommand() are move to query_utils.c. handle_help_version_opts() is moved to option_utils.c. Mark Dilger, reviewed by me. The larger patch series of which this is a part has also had review from Peter Geoghegan, Andres Freund, Álvaro Herrera, Michael Paquier, and Amul Sul, but I don't know whether any of them have reviewed this bit specifically. Discussion: http://postgr.es/m/12ED3DA8-25F0-4B68-937D-D907CFBF08E7@enterprisedb.com Discussion: http://postgr.es/m/5F743835-3399-419C-8324-2D424237E999@enterprisedb.com Discussion: http://postgr.es/m/70655DF3-33CE-4527-9A4D-DDEB582B6BA0@enterprisedb.com