This is the main PostgreSQL git repository. http://git.postgresql.org/cgit/postgresql.git/atom?h=REL9_2_STABLE 2024-11-27T03:31:41Z 2024-11-27T03:31:41Z Thomas Munro 2024-11-27T02:43:18Z urn:sha1:0c7171b32e6407c9ed65a444d0a104d0770d957d Branches before 16 can't be compiled with a C23 compiler (see deprecation warnings silenced by commit f9a56e72, and non-back-patchable changes made in 16 by commit 1c27d16e). Test __STDC_VERSION__, and if it's above C17 then try appending -std=gnu17. The test is done with the user's CFLAGS, so an acceptable language version can also be configured manually that way. This is done in branches 15 and older, back to 9.2, per policy of keeping them buildable with modern tools. Discussion: https://postgr.es/m/87o72eo9iu.fsf%40gentoo.org 2022-09-21T19:42:00Z Tom Lane 2022-09-21T19:42:00Z urn:sha1:b8464d2f5da0d1abe0925c5712d0c4810986e629 Back-port commit 16fbac39f into 9.3 and 9.2, so that these out-of-support branches can be built with clang without wading through a pile of warnings about strlcpy and related functions. check_decls.m4 required some adaptation to work with autoconf 2.63, but nothing too major. Discussion: https://postgr.es/m/26819.1542515567@sss.pgh.pa.us Discussion: https://postgr.es/m/1081321.1663775084@sss.pgh.pa.us 2022-09-20T22:59:54Z Tom Lane 2022-09-20T22:59:54Z urn:sha1:5d3ce0d823c8133f22f65d858970b55747ebbb08 There doesn't seem to be any good ABI-preserving way to silence clang 15's -Wdeprecated-non-prototype warnings about our tree-walk APIs. While we've fixed it properly in HEAD, the only way to not see hundreds of these in the back branches is to disable the warnings. We're not going to do anything about them, so we might as well disable them. I noticed that we also get some of these warnings about fmgr.c's support for V0 function call convention, in branches before v10 where we removed that. That's another area we aren't going to change, so turning off the warning seems fine for that too. Per project policy, this is a candidate for back-patching into out-of-support branches: it suppresses annoying compiler warnings but changes no behavior. Hence, back-patch all the way to 9.2. Discussion: https://postgr.es/m/CA+hUKGKpHPDTv67Y+s6yiC8KH5OXeDg6a-twWo_xznKTcG0kSA@mail.gmail.com 2021-12-13T06:28:13Z Tom Lane 2021-12-13T06:28:13Z urn:sha1:cea316881f1f109fe06243f1294313ead913b498 In 9.2, we didn't yet teach the compiler that elog(ERROR) doesn't return, which means that the compiler's opinion about whether variable dereferences are reachable isn't worth much. Back-patching the commits that fixed that seems unduly invasive, so instead silence related complaints with a big hammer. -Wsometimes-uninitialized is a clang-ism; gcc seems to spell this warning option differently. However, I do not observe any such compiler warnings in 9.2 with gcc 11.2.1, so for now we needn't do anything for gcc. Discussion: https://postgr.es/m/d0316012-ece7-7b7e-2d36-9c38cb77cb3b@enterprisedb.com 2021-12-12T23:06:15Z Tom Lane 2021-12-12T23:06:15Z urn:sha1:ebd952f3f453d3074b99632e07d54f3dc5eb55d1 clang-12 has introduced -Wcompound-token-split-by-macro, that is causing a large amount of warnings when building PL/Perl because of its interactions with upstream Perl. This commit adds one -Wno to CFLAGS at ./configure time if the flag is supported by the compiler to silence all those warnings. This back-patches commit 9ff47ea41 into out-of-support branches, pursuant to newly-established project policy. The point is to suppress scary-looking warnings so that people building these branches needn't expend brain cells verifying that it's safe to ignore the warnings. Discussion: https://postgr.es/m/d0316012-ece7-7b7e-2d36-9c38cb77cb3b@enterprisedb.com 2021-12-12T21:46:14Z Tom Lane 2021-12-12T21:46:14Z urn:sha1:276c017f12fe6ecbd07bebaff00768ec34f2ea21 This back-patches commit e71658523 into out-of-support branches, pursuant to newly-established project policy. The point is to suppress scary-looking warnings so that people building these branches needn't expend brain cells verifying that it's safe to ignore the warnings. Also back-patch the adjacent test from commit 73b416b2e (Suppress clang's unhelpful gripes about -pthread switch being unused) and the necessary autoconf macro from fdea2530b. Discussion: https://postgr.es/m/d0316012-ece7-7b7e-2d36-9c38cb77cb3b@enterprisedb.com 2017-11-06T22:17:39Z Tom Lane 2017-11-06T22:17:39Z urn:sha1:8786f783ab2398468a8c4d8eac937fc6533d16e3 2017-09-01T19:14:18Z Tom Lane 2017-09-01T19:14:18Z urn:sha1:f60a236bab805c2aaf6818940f1b2ce04f4a7081 Instead of using a cast to force the constant to be the right width, assume we can plaster on an L, UL, LL, or ULL suffix as appropriate. The old approach to this is very hoary, dating from before we were willing to require compilers to have working int64 types. This fix makes the PG_INT64_MIN, PG_INT64_MAX, and PG_UINT64_MAX constants safe to use in preprocessor conditions, where a cast doesn't work. Other symbolic constants that might be defined using [U]INT64CONST are likewise safer than before. Also fix the SIZE_MAX macro to be similarly safe, if we are forced to provide a definition for that. The test added in commit 2e70d6b5e happens to do what we want even with the hack "(size_t) -1" definition, but we could easily get burnt on other tests in future. Back-patch to all supported branches, like the previous commits. Discussion: https://postgr.es/m/15883.1504278595@sss.pgh.pa.us 2017-08-28T21:30:10Z Tom Lane 2017-08-28T21:30:10Z urn:sha1:2f4ffae5ada6ec272997ce1d6fe415eb9a025924 2017-08-07T21:19:50Z Tom Lane 2017-08-07T21:19:50Z urn:sha1:56fc4f7c9c8168b93b45ccf48781d77073d271dc