summaryrefslogtreecommitdiff
path: root/src/tools
AgeCommit message (Collapse)Author
2017-08-14Final pgindent + perltidy run for v10.Tom Lane
2017-08-14Absorb -D_USE_32BIT_TIME_T switch from Perl, if relevant.Tom Lane
Commit 3c163a7fc's original choice to ignore all #define symbols whose names begin with underscore turns out to be too simplistic. On Windows, some Perl installations are built with -D_USE_32BIT_TIME_T, and we must absorb that or we get the wrong result for sizeof(PerlInterpreter). This effectively re-reverts commit ef58b87df, which injected that symbol in a hacky way, making it apply to all of Postgres not just PL/Perl. More significantly, it did so on *all* 32-bit Windows builds, even when the Perl build to be used did not select this option; so that it fails to work properly with some newer Perl builds. By making this change, we would be introducing an ABI break in 32-bit Windows builds; but fortunately we have not used type time_t in any exported Postgres APIs in a long time. So it should be OK, both for PL/Perl itself and for third-party extensions, if an extension library is built with a different _USE_32BIT_TIME_T setting than the core code. Patch by me, based on research by Ashutosh Sharma and Robert Haas. Back-patch to all supported branches, as commit 3c163a7fc was. Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-08-07Update RELEASE_CHANGES' example of branch name format.Tom Lane
We're planning to put an underscore before the major version number in branch names for v10 and later. Make sure the recipe in RELEASE_CHANGES reflects that. In passing, add a reminder to consider doing pgindent right before the branch. Discussion: https://postgr.es/m/[email protected]
2017-07-28PL/Perl portability fix: absorb relevant -D switches from Perl.Tom Lane
The Perl documentation is very clear that stuff calling libperl should be built with the compiler switches shown by Perl's $Config{ccflags}. We'd been ignoring that up to now, and mostly getting away with it, but recent Perl versions contain ABI compatibility cross-checks that fail on some builds because of this omission. In particular the sizeof(PerlInterpreter) can come out different due to some fields being added or removed; which means we have a live ABI hazard that we'd better fix rather than continuing to sweep it under the rug. However, it still seems like a bad idea to just absorb $Config{ccflags} verbatim. In some environments Perl was built with a different compiler that doesn't even use the same switch syntax. -D switch syntax is pretty universal though, and absorbing Perl's -D switches really ought to be enough to fix the problem. Furthermore, Perl likes to inject stuff like -D_LARGEFILE_SOURCE and -D_FILE_OFFSET_BITS=64 into $Config{ccflags}, which affect libc ABIs on platforms where they're relevant. Adopting those seems dangerous too. It's unclear whether a build wherein Perl and Postgres have different ideas of sizeof(off_t) etc would work, or whether anyone would care about making it work. But it's dead certain that having different stdio ABIs in core Postgres and PL/Perl will not work; we've seen that movie before. Therefore, let's also ignore -D switches for symbols beginning with underscore. The symbols that we actually need to import should be the ones mentioned in perl.h's PL_bincompat_options stanza, and none of those start with underscore, so this seems likely to work. (If it turns out not to work everywhere, we could consider intersecting the symbols mentioned in PL_bincompat_options with the -D switches. But that will be much more complicated, so let's try this way first.) This will need to be back-patched, but first let's see what the buildfarm makes of it. Ashutosh Sharma, some adjustments by me Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-24MSVC: Finish clean.bat build artifact coverage.Noah Misch
With this, "git clean -dnx" is clear after a "clean dist" following a build. Preserve sql_help.h in non-dist cleans, like the Makefile does.
2017-07-24MSVC: Accept tcl86.lib in addition to tcl86t.lib.Noah Misch
ActiveTcl8.6.4.1.299124-win32-x86_64-threaded.exe ships just tcl86.lib. Back-patch to 9.2, like the commit recognizing tcl86t.lib.
2017-07-21Use MINVALUE/MAXVALUE instead of UNBOUNDED for range partition bounds.Dean Rasheed
Previously, UNBOUNDED meant no lower bound when used in the FROM list, and no upper bound when used in the TO list, which was OK for single-column range partitioning, but problematic with multiple columns. For example, an upper bound of (10.0, UNBOUNDED) would not be collocated with a lower bound of (10.0, UNBOUNDED), thus making it difficult or impossible to define contiguous multi-column range partitions in some cases. Fix this by using MINVALUE and MAXVALUE instead of UNBOUNDED to represent a partition column that is unbounded below or above respectively. This syntax removes any ambiguity, and ensures that if one partition's lower bound equals another partition's upper bound, then the partitions are contiguous. Also drop the constraint prohibiting finite values after an unbounded column, and just document the fact that any values after MINVALUE or MAXVALUE are ignored. Previously it was necessary to repeat UNBOUNDED multiple times, which was needlessly verbose. Note: Forces a post-PG 10 beta2 initdb. Report by Amul Sul, original patch by Amit Langote with some additional hacking by me. Discussion: https://postgr.es/m/CAAJ_b947mowpLdxL3jo3YLKngRjrq9+Ej4ymduQTfYR+8=YAYQ@mail.gmail.com
2017-07-17MSVC: Don't link libpgcommon into pgcrypto.Noah Misch
Doing so was useful in 273c458a2b3a0fb73968020ea5e9e35eb6928967 but became obsolete when 818fd4a67d610991757b610755e3065fb99d80a5 caused postgres.exe to provide the relevant symbols. No other loadable module links to libpgcommon directly.
2017-07-16fix typoAndrew Dunstan
2017-07-16Fix vcregress.pl PROVE_FLAGS bug in commit 93b7d9731fAndrew Dunstan
This change didn't adjust the publicly visible taptest function, causing buildfarm failures on bowerbird. Backpatch to 9.4 like previous change.
2017-07-14Fix broken link-command-line ordering for libpgfeutils.Tom Lane
In the frontend Makefiles that pull in libpgfeutils, we'd generally done it like this: LDFLAGS += -L$(top_builddir)/src/fe_utils -lpgfeutils $(libpq_pgport) That method is badly broken, as seen in bug #14742 from Chris Ruprecht. The -L flag for src/fe_utils ends up being placed after whatever random -L flags are in LDFLAGS already. That puts us at risk of pulling in libpgfeutils.a from some previous installation rather than the freshly built one in src/fe_utils. Also, the lack of an "override" is hazardous if someone tries to specify some LDFLAGS on the make command line. The correct way to do it is like this: override LDFLAGS := -L$(top_builddir)/src/fe_utils -lpgfeutils $(libpq_pgport) $(LDFLAGS) so that libpgfeutils, along with libpq, libpgport, and libpgcommon, are guaranteed to be pulled in from the build tree and not from any referenced system directory, because their -L flags will appear first. In some places we'd been even lazier and done it like this: LDFLAGS += -L$(top_builddir)/src/fe_utils -lpgfeutils -lpq which is subtly wrong in an additional way: on platforms where we can't restrict the symbols exported by libpq.so, it allows libpgfeutils to latch onto libpgport and libpgcommon symbols from libpq.so, rather than directly from those static libraries as intended. This carries hazards like those explained in the comments for the libpq_pgport macro. In addition to fixing the broken libpgfeutils usages, I tried to standardize on using $(libpq_pgport) like so: override LDFLAGS := $(libpq_pgport) $(LDFLAGS) even where libpgfeutils is not in the picture. This makes no difference right now but will hopefully discourage future mistakes of the same ilk. And it's more like the way we handle CPPFLAGS in libpq-using Makefiles. In passing, just for consistency, make pgbench include PTHREAD_LIBS the same way everyplace else does, ie just after LIBS rather than in some random place in the command line. This might have practical effect if there are -L switches in that macro on some platform. It looks to me like the MSVC build scripts are not affected by this error, but someone more familiar with them than I might want to double check. Back-patch to 9.6 where libpgfeutils was introduced. In 9.6, the hazard this error creates is that a reinstallation might link to the prior installation's copy of libpgfeutils.a and thereby fail to absorb a minor-version bug fix. Discussion: https://postgr.es/m/[email protected]
2017-07-09MSVC: Repair libpq.rc generator.Noah Misch
It generates an empty file, so libpq.dll advertises no version information. Commit facde2a98f0b5f7689b4e30a9e7376e926e733b8 mistranslated "print O;" in this one place.
2017-06-28Ooops, WIN32 code in pg_ctl.c still needs PQExpBuffer.Tom Lane
Per buildfarm.
2017-06-28Change pg_ctl to detect server-ready by watching status in postmaster.pid.Tom Lane
Traditionally, "pg_ctl start -w" has waited for the server to become ready to accept connections by attempting a connection once per second. That has the major problem that connection issues (for instance, a kernel packet filter blocking traffic) can't be reliably told apart from server startup issues, and the minor problem that if server startup isn't quick, we accumulate "the database system is starting up" spam in the server log. We've hacked around many of the possible connection issues, but it resulted in ugly and complicated code in pg_ctl.c. In commit c61559ec3, I changed the probe rate to every tenth of a second. That prompted Jeff Janes to complain that the log-spam problem had become much worse. In the ensuing discussion, Andres Freund pointed out that we could dispense with connection attempts altogether if the postmaster were changed to report its status in postmaster.pid, which "pg_ctl start" already relies on being able to read. This patch implements that, teaching postmaster.c to report a status string into the pidfile at the same state-change points already identified as being of interest for systemd status reporting (cf commit 7d17e683f). pg_ctl no longer needs to link with libpq at all; all its functions now depend on reading server files. In support of this, teach AddToDataDirLockFile() to allow addition of postmaster.pid lines in not-necessarily-sequential order. This is needed on Windows where the SHMEM_KEY line will never be written at all. We still have the restriction that we don't want to truncate the pidfile; document the reasons for that a bit better. Also, fix the pg_ctl TAP tests so they'll notice if "start -w" mode is broken --- before, they'd just wait out the sixty seconds until the loop gives up, and then report success anyway. (Yes, I found that out the hard way.) While at it, arrange for pg_ctl to not need to #include miscadmin.h; as a rather low-level backend header, requiring that to be compilable client-side is pretty dubious. This requires moving the #define's associated with the pidfile into a new header file, and moving PG_BACKEND_VERSIONSTR someplace else. For lack of a clearly better "someplace else", I put it into port.h, beside the declaration of find_other_exec(), since most users of that macro are passing the value to find_other_exec(). (initdb still depends on miscadmin.h, but at least pg_ctl and pg_upgrade no longer do.) In passing, fix main.c so that PG_BACKEND_VERSIONSTR actually defines the output of "postgres -V", which remarkably it had never done before. Discussion: https://postgr.es/m/CAMkU=1xJW8e+CTotojOMBd-yzUvD0e_JZu2xHo=MnuZ4__m7Pg@mail.gmail.com
2017-06-21Remove entab and associated detritus.Tom Lane
We don't need this anymore, because pg_bsd_indent has been taught to follow the same tab-vs-space rules that entab used to enforce. Discussion: https://postgr.es/m/[email protected] Discussion: https://postgr.es/m/[email protected]
2017-06-21Phase 3 of pgindent updates.Tom Lane
Don't move parenthesized lines to the left, even if that means they flow past the right margin. By default, BSD indent lines up statement continuation lines that are within parentheses so that they start just to the right of the preceding left parenthesis. However, traditionally, if that resulted in the continuation line extending to the right of the desired right margin, then indent would push it left just far enough to not overrun the margin, if it could do so without making the continuation line start to the left of the current statement indent. That makes for a weird mix of indentations unless one has been completely rigid about never violating the 80-column limit. This behavior has been pretty universally panned by Postgres developers. Hence, disable it with indent's new -lpl switch, so that parenthesized lines are always lined up with the preceding left paren. This patch is much less interesting than the first round of indent changes, but also bulkier, so I thought it best to separate the effects. Discussion: https://postgr.es/m/[email protected] Discussion: https://postgr.es/m/[email protected]
2017-06-21Phase 2 of pgindent updates.Tom Lane
Change pg_bsd_indent to follow upstream rules for placement of comments to the right of code, and remove pgindent hack that caused comments following #endif to not obey the general rule. Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using the published version of pg_bsd_indent, but a hacked-up version that tried to minimize the amount of movement of comments to the right of code. The situation of interest is where such a comment has to be moved to the right of its default placement at column 33 because there's code there. BSD indent has always moved right in units of tab stops in such cases --- but in the previous incarnation, indent was working in 8-space tab stops, while now it knows we use 4-space tabs. So the net result is that in about half the cases, such comments are placed one tab stop left of before. This is better all around: it leaves more room on the line for comment text, and it means that in such cases the comment uniformly starts at the next 4-space tab stop after the code, rather than sometimes one and sometimes two tabs after. Also, ensure that comments following #endif are indented the same as comments following other preprocessor commands such as #else. That inconsistency turns out to have been self-inflicted damage from a poorly-thought-through post-indent "fixup" in pgindent. This patch is much less interesting than the first round of indent changes, but also bulkier, so I thought it best to separate the effects. Discussion: https://postgr.es/m/[email protected] Discussion: https://postgr.es/m/[email protected]
2017-06-21Initial pgindent run with pg_bsd_indent version 2.0.Tom Lane
The new indent version includes numerous fixes thanks to Piotr Stefaniak. The main changes visible in this commit are: * Nicer formatting of function-pointer declarations. * No longer unexpectedly removes spaces in expressions using casts, sizeof, or offsetof. * No longer wants to add a space in "struct structname *varname", as well as some similar cases for const- or volatile-qualified pointers. * Declarations using PG_USED_FOR_ASSERTS_ONLY are formatted more nicely. * Fixes bug where comments following declarations were sometimes placed with no space separating them from the code. * Fixes some odd decisions for comments following case labels. * Fixes some cases where comments following code were indented to less than the expected column 33. On the less good side, it now tends to put more whitespace around typedef names that are not listed in typedefs.list. This might encourage us to put more effort into typedef name collection; it's not really a bug in indent itself. There are more changes coming after this round, having to do with comment indentation and alignment of lines appearing within parentheses. I wanted to limit the size of the diffs to something that could be reviewed without one's eyes completely glazing over, so it seemed better to split up the changes as much as practical. Discussion: https://postgr.es/m/[email protected] Discussion: https://postgr.es/m/[email protected]
2017-06-21Adjust pgindent script to use pg_bsd_indent 2.0.Tom Lane
Update version-checking code and list of switches. Delete obsolete quasi-support for using GNU indent. Remove a lot of no-longer-needed workarounds for bugs of the old version, and improve comments for the hacks that remain. Update run_build() subroutine to fetch the pg_bsd_indent code from the newly established git repo for it. In passing, fix pgindent to not overwrite files that require no changes; this makes it a bit more friendly to run on a built tree. Adjust relevant documentation. Remove indent.bsd.patch; it's not relevant anymore (and was obsolete long ago anyway). Likewise remove pgcppindent, since we're no longer in the business of shipping C++ code. Piotr Stefaniak is responsible for most of the algorithmic changes to the pgindent script; I did the rest. Discussion: https://postgr.es/m/[email protected] Discussion: https://postgr.es/m/[email protected]
2017-06-21Final pgindent run with old pg_bsd_indent (version 1.3).Tom Lane
This is just to have a clean basis for comparison with the results of the new version (which will indeed end up reverting some of these changes...) Discussion: https://postgr.es/m/[email protected] Discussion: https://postgr.es/m/[email protected]
2017-06-17Teach pgindent to skip files generated by bison or flex automatically.Tom Lane
If a .c or .h file corresponds to a .y or .l file, skip indenting it. There's no point in reindenting derived files, and these files tend to confuse pgindent. (Which probably indicates a bug in BSD indent, but I can't get excited about trying to fix it.) For the same reasons, add src/backend/utils/fmgrtab.c to the set of files excluded by src/tools/pgindent/exclude_file_patterns. The point of doing this is that it makes it safe to run pgindent over the tree without doing "make maintainer-clean" first. While these are not the only derived .c/.h files in the tree, they are the only ones pgindent fails on. Removing that prerequisite step results in one less way to mess up a pgindent run, and it's necessary if we ever hope to get to the ease of running pgindent via "make indent".
2017-06-13Use correct ICU path for Windows 32 vs. 64 bitPeter Eisentraut
Author: Ashutosh Sharma <[email protected]>
2017-06-12Add MSVC build system support for ICUPeter Eisentraut
Author: Ashutosh Sharma <[email protected]> Reviewed-by: Michael Paquier <[email protected]>
2017-06-10Take PROVE_FLAGS from the command line but not the environmentAndrew Dunstan
This reverts commit 56b6ef893fee9e9bf47d927a02f4d1ea911f4d9c and instead makes vcregress.pl parse out PROVE_FLAGS from a command line argument when doing a TAP test, thus making it consistent with the makefile treatment. Discussion: https://postgr.es/m/c26a7416-2fb9-34ab-7991-618c922f896e%402ndquadrant.com Backpatch to 9.4 like previous patch.
2017-06-06Fix thinko in previous openssl changeAndrew Dunstan
2017-06-05Find openssl lib files in right directory for MSVCAndrew Dunstan
Some openssl builds put their lib files in a VC subdirectory, others do not. Cater for both cases. Backpatch to all live branches. From an offline discussion with Leonardo Cecchi.
2017-05-23Update URLs in pgindent source and READMEMagnus Hagander
Website and buildfarm is https, not http, and the ftp protocol will be shut down shortly.
2017-05-17Post-PG 10 beta1 pgperltidy runBruce Momjian
2017-05-17Post-PG 10 beta1 pgindent runBruce Momjian
perltidy run not included.
2017-05-17Update typedefs list in prep. for post-PG10 beta1 pgindent runBruce Momjian
2017-05-17Add download URL for perltidy version v20090616Bruce Momjian
2017-05-15Update oidjoins regression test for v10.Tom Lane
2017-05-12Honor PROVE_FLAGS environment settingAndrew Dunstan
On MSVC builds and on back branches that means removing the hardcoded --verbose setting. On master for Unix that means removing the empty setting in the global Makefile so that the value can be acquired from the environment as well as from the make arguments. Backpatch to 9.4 where we introduced TAP tests
2017-05-12Add libxml2 include path for MSVC buildsAndrew Dunstan
On Unix this path is detected via the use of xml2-config, but that's not available on Windows. This means that users building with libxml2 will no longer need to move things around from the standard libxml2 installation for MSVC builds. Backpatch to all live branches.
2017-05-09pgindent: use HTTP instead of FTP to retrieve pg_bsd_indent srcBruce Momjian
FTP support will be removed from ftp.postgresql.org in months, but http still works. Typedefs already used http.
2017-05-07Install the "posixrules" timezone link in MSVC builds.Tom Lane
Somehow, we'd missed ever doing this. The consequences aren't too severe: basically, the timezone library would fall back on its hardwired notion of the DST transition dates to use for a POSIX-style zone name, rather than obeying US/Eastern which is the intended behavior. The net effect would only be to obey current US DST law further back than it ought to apply; so it's not real surprising that nobody noticed. David Rowley, per report from Amit Kapila Discussion: https://postgr.es/m/CAA4eK1LC7CaNhRAQ__C3ht1JVrPzaAXXhEJRnR5L6bfYHiLmWw@mail.gmail.com
2017-05-05Allow MSVC to build with Tcl 8.6.Alvaro Herrera
Commit eaba54c20c5 added support for Tcl 8.6 for configure-supported platforms after verifying that pltcl works without further changes, but the MSVC tooling wasn't updated accordingly. Update MSVC to match, restructuring the code to avoid duplicating the logic for every Tcl version supported. Backpatch to all live branches, like eaba54c20c5. In 9.4 and previous, change the patch to use backslashes rather than forward, as in the rest of the file. Reported by Paresh More, who also tested the patch I provided. Discussion: https://postgr.es/m/CAAgiCNGVw3ssBtSi3ZNstrz5k00ax=UV+_ZEHUeW_LMSGL2sew@mail.gmail.com
2017-05-05Build pgoutput.dll in MSVC buildMagnus Hagander
Without this, logical replication obviously does not work on Windows MauMau, with clean.bet additions from me per note from Michael Paquier
2017-05-02Fix perl thinko in commit fed6df486dcaAndrew Dunstan
Report and fix from Vaishnavi Prabakaran Backpatch to 9.4 like original.
2017-05-01Allow vcregress.pl to run an arbitrary TAP test setAndrew Dunstan
Currently only provision for running the bin checks in a single step is provided for. Now these tests can be run individually, as well as tests in other locations (e.g. src.test/recover). Also provide for suppressing unnecessary temp installs by setting the NO_TEMP_INSTALL environment variable just as the Makefiles do. Backpatch to 9.4.
2017-04-13docs: update major release instructionsBruce Momjian
2017-04-13git_changelog: improve commentBruce Momjian
2017-04-12git_changelog: improve instructions for finding branch commitsBruce Momjian
Specifically, use '--summary' with 'git show'.
2017-04-11Remove bogus redefinition of _MSC_VER.Tom Lane
Commit a4777f355 was a shade too mechanical: we don't want to override MSVC's own definition of _MSC_VER, as that breaks tests on its numerical value. Per buildfarm.
2017-04-11Remove symbol WIN32_ONLY_COMPILERMagnus Hagander
This used to mean "Visual C++ except in those parts where Borland C++ was supported where it meant one of those". Now that we don't support Borland C++ anymore, simplify by using _MSC_VER which is the normal way to detect Visual C++.
2017-04-07Use SASLprep to normalize passwords for SCRAM authentication.Heikki Linnakangas
An important step of SASLprep normalization, is to convert the string to Unicode normalization form NFKC. Unicode normalization requires a fairly large table of character decompositions, which is generated from data published by the Unicode consortium. The script to generate the table is put in src/common/unicode, as well test code for the normalization. A pre-generated version of the tables is included in src/include/common, so you don't need the code in src/common/unicode to build PostgreSQL, only if you wish to modify the normalization tables. The SASLprep implementation depends on the UTF-8 functions from src/backend/utils/mb/wchar.c. So to use it, you must also compile and link that. That doesn't change anything for the current users of these functions, the backend and libpq, as they both already link with wchar.o. It would be good to move those functions into a separate file in src/commmon, but I'll leave that for another day. No documentation changes included, because there is no details on the SCRAM mechanism in the docs anyway. An overview on that in the protocol specification would probably be good, even though SCRAM is documented in detail in RFC5802. I'll write that as a separate patch. An important thing to mention there is that we apply SASLprep even on invalid UTF-8 strings, to support other encodings. Patch by Michael Paquier and me. Discussion: https://www.postgresql.org/message-id/CAB7nPqSByyEmAVLtEf1KxTRh=PWNKiWKEKQR=e1yGehz=wbymQ@mail.gmail.com
2017-04-06Fix integer-overflow problems in interval comparison.Tom Lane
When using integer timestamps, the interval-comparison functions tried to compute the overall magnitude of an interval as an int64 number of microseconds. As reported by Frazer McLean, this overflows for intervals exceeding about 296000 years, which is bad since we nominally allow intervals many times larger than that. That results in wrong comparison results, and possibly in corrupted btree indexes for columns containing such large interval values. To fix, compute the magnitude as int128 instead. Although some compilers have native support for int128 calculations, many don't, so create our own support functions that can do 128-bit addition and multiplication if the compiler support isn't there. These support functions are designed with an eye to allowing the int128 code paths in numeric.c to be rewritten for use on all platforms, although this patch doesn't do that, or even provide all the int128 primitives that will be needed for it. Back-patch as far as 9.4. Earlier releases did not guard against overflow of interval values at all (commit 146604ec4 fixed that), so it seems not very exciting to worry about overly-large intervals for them. Before 9.6, we did not assume that unreferenced "static inline" functions would not draw compiler warnings, so omit functions not directly referenced by timestamp.c, the only present consumer of int128.h. (We could have omitted these functions in HEAD too, but since they were written and debugged on the way to the present patch, and they look likely to be needed by numeric.c, let's keep them in HEAD.) I did not bother to try to prevent such warnings in a --disable-integer-datetimes build, though. Before 9.5, configure will never define HAVE_INT128, so the part of int128.h that exploits a native int128 implementation is dead code in the 9.4 branch. I didn't bother to remove it, thinking that keeping the file looking similar in different branches is more useful. In HEAD only, add a simple test harness for int128.h in src/tools/. In back branches, this does not change the float-timestamps code path. That's not subject to the same kind of overflow risk, since it computes the interval magnitude as float8. (No doubt, when this code was originally written, overflow was disregarded for exactly that reason.) There is a precision hazard instead :-(, but we'll avert our eyes from that question, since no complaints have been reported and that code's deprecated anyway. Kyotaro Horiguchi and Tom Lane Discussion: https://postgr.es/m/[email protected]
2017-04-02Remove reinvention of stringify macro.Tom Lane
We already have CppAsString2, there's no need for the MSVC support to re-invent a macro to do that (and especially not to inject it in as ugly a way as this). Discussion: https://postgr.es/m/CADkLM=c+hm2rc0tkKgC-ZgrLttHT2KkfppE+BC-=i-xj+7V-TQ@mail.gmail.com
2017-03-28Fix Perl code which had broken the Windows buildPeter Eisentraut
The previous change wanted to avoid modifying $_ in grep, but the code just made the change in a local variable and then lost it. Rewrite the code using a separate map and grep, which is clearer anyway. Author: Dagfinn Ilmari MannsÃ¥ker <[email protected]>
2017-03-27Clean up Perl code according to perlcriticPeter Eisentraut
Fix all perlcritic warnings of severity level 5, except in src/backend/utils/Gen_dummy_probes.pl, which is automatically generated. Reviewed-by: Dagfinn Ilmari MannsÃ¥ker <[email protected]> Reviewed-by: Daniel Gustafsson <[email protected]>