pgsql: Require stdint.h

2020-02-21 Thread Peter Eisentraut
Require stdint.h stdint.h belongs to the compiler (as opposed to inttypes.h), so by requiring a C99 compiler we can also require stdint.h unconditionally. Remove configure checks and other workarounds for it. This also removes a few steps in the required portability adjustments to the imported t

pgsql: Avoid redundant checks in partition_bounds_copy().

2020-02-21 Thread Etsuro Fujita
Avoid redundant checks in partition_bounds_copy(). Previously, partition_bounds_copy() checked whether the strategy for the given partition bounds was hash or not, and then determined the number of elements in the datums in the datums array for the partition bounds, on each iteration of the loop f

pgsql: Fixup for nodeAgg.c refactor.

2020-02-21 Thread Jeff Davis
Fixup for nodeAgg.c refactor. Commit 5b618e1f made an unintended behavior change. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/b7fabe80df9a65010bfe5e5d0a979bacebfec382 Modified Files -- src/backend/executor/nodeAgg.c | 5 - 1 file changed, 4 inser

pgsql: Fix compiler warnings on 64-bit Windows

2020-02-21 Thread Peter Eisentraut
Fix compiler warnings on 64-bit Windows GCC reports various instances of warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] and MSVC equivalently warning C4312: 'type cast': conversion f

pgsql: Assume that we have utime() and .

2020-02-21 Thread Tom Lane
Assume that we have utime() and . These are required by POSIX since SUSv2, and no live platforms fail to provide them. On Windows, utime() exists and we bring our own , so we're good there too. So remove the configure probes and ad-hoc substitute code. We don't need to check for utimes() anymor

pgsql: Assume that we have memmove().

2020-02-21 Thread Tom Lane
Assume that we have memmove(). Windows has this, and so do all other live platforms according to the buildfarm, so remove the configure probe and c.h's substitute code. This is part of a series of commits to get rid of no-longer-relevant configure checks and dead src/port/ code. I'm committing t

pgsql: Assume that we have signed integral types and flexible array mem

2020-02-21 Thread Tom Lane
Assume that we have signed integral types and flexible array members. These compiler features are required by C99, so remove the configure probes for them. This is part of a series of commits to get rid of no-longer-relevant configure checks and dead src/port/ code. I'm committing them separatel

pgsql: Assume that we have .

2020-02-21 Thread Tom Lane
Assume that we have . Windows has this, and so do all other live platforms according to the buildfarm; it's been required by POSIX since SUSv2. So remove the configure probe and tests of HAVE_WCHAR_H. This is part of a series of commits to get rid of no-longer-relevant configure checks and dead

pgsql: Assume that we have functional, 64-bit fseeko()/ftello().

2020-02-21 Thread Tom Lane
Assume that we have functional, 64-bit fseeko()/ftello(). Windows has this, and so do all other live platforms according to the buildfarm, so remove the configure probe and src/port/ substitution. Keep the probe that detects whether _LARGEFILE_SOURCE has to be defined to get that, though ... that

pgsql: Assume that we have cbrt().

2020-02-21 Thread Tom Lane
Assume that we have cbrt(). Windows has this, and so do all other live platforms according to the buildfarm, so remove the configure probe and float.c's substitute code. This is part of a series of commits to get rid of no-longer-relevant configure checks and dead src/port/ code. I'm committing

pgsql: Assume that we have isinf().

2020-02-21 Thread Tom Lane
Assume that we have isinf(). Windows has this, and so do all other live platforms according to the buildfarm, so remove the configure probe and src/port/ substitution. This also lets us get rid of some configure probes that existed only to support src/port/isinf.c. I kept the port.h hack to forc

pgsql: Assume that we have rint().

2020-02-21 Thread Tom Lane
Assume that we have rint(). Windows has this since _MSC_VER >= 1200, and so do all other live platforms according to the buildfarm, so remove the configure probe and src/port/ substitution. This is part of a series of commits to get rid of no-longer-relevant configure checks and dead src/port/ co

pgsql: Allow running src/tools/msvc/mkvcbuild.pl under not Windows

2020-02-21 Thread Peter Eisentraut
Allow running src/tools/msvc/mkvcbuild.pl under not Windows This to allow verifying the MSVC build file generation without having to have Windows. To do this, we avoid Windows-specific Perl modules and don't run the "cl" compiler or "nmake". The resulting build files won't actually be completely

pgsql: Fix perlcritic warnings

2020-02-21 Thread Peter Eisentraut
Fix perlcritic warnings Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/b24e125696a94b6ebdd2262c0c41bf45cbeba23f Modified Files -- src/tools/msvc/Mkvcbuild.pm | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-)

pgsql: Adjust Solution.pm to set HAVE_STDINT_H.

2020-02-21 Thread Tom Lane
Adjust Solution.pm to set HAVE_STDINT_H. We're not testing that anywhere anymore, but for consistency, it should get defined. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/ec4a7851d5914bbdc5b65175e2489ec19020217e Modified Files -- src/tools/msvc/Solut

Re: pgsql: Assume that we have signed integral types and flexible array mem

2020-02-21 Thread Peter Geoghegan
On Fri, Feb 21, 2020 at 11:31 AM Tom Lane wrote: > Assume that we have signed integral types and flexible array members. I see this change to c.h: +/* + * We require C99, hence the compiler should understand flexible array + * members. However, for documentation purposes we still consider it to

Re: pgsql: Assume that we have signed integral types and flexible array mem

2020-02-21 Thread Tom Lane
Peter Geoghegan writes: > I see this change to c.h: > +/* > + * We require C99, hence the compiler should understand flexible array > + * members. However, for documentation purposes we still consider it to be > + * project style to write "field[FLEXIBLE_ARRAY_MEMBER]" not just "field[]". > + *

Re: pgsql: Assume that we have signed integral types and flexible array mem

2020-02-21 Thread Peter Geoghegan
On Fri, Feb 21, 2020 at 2:52 PM Tom Lane wrote: > > Why not just get rid of the FLEXIBLE_ARRAY_MEMBER hack altogether? > > As I said in the comment, I think it's good style. I disagree. It doesn't seem important enough to make a fuss over, though. > Even if you disagree, we shouldn't remove the