aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAge
...
* Fix typos and inconsistencies in code commentsMichael Paquier2019-06-14
| | | | | Author: Alexander Lakhin Discussion: https://postgr.es/m/dec6aae8-2d63-639f-4d50-20e229fb83e3@gmail.com
* Use OpenSSL-specific ifdefs in sha2.hMichael Paquier2019-06-14
| | | | | | | | | | In order to separate OpenSSL's SHA symbols, this header has been using USE_SSL, which is equivalent to USE_OPENSSL. There is now only one SSL implementation included in the tree, so this works fine, but when adding a new SSL implementation this would run into failures. Author: Daniel Gustafsson Discussion: https://postgr.es/m/0DF29010-CE26-4F51-85A6-9C8ABF5536F9@yesql.se
* Avoid combinatorial explosion in add_child_rel_equivalences().Tom Lane2019-06-13
| | | | | | | | | | | | | | | | | | | | | | | | If an EquivalenceClass member expression includes variables from multiple appendrels, then instead of producing one substituted expression per child relation as intended, we'd create additional child expressions for combinations of children of different appendrels. This happened because the child expressions generated while considering the first appendrel were taken as sources during substitution of the second appendrel, and so on. The extra expressions are useless, and are harmless unless there are too many of them --- but if you have several appendrels with a thousand or so members each, it gets bad fast. To fix, consider only original (non-em_is_child) EC members as candidates to be expanded. This requires the ability to substitute directly from a top parent relation's Vars to those of an indirect descendant relation, but we already have that in adjust_appendrel_attrs_multilevel(). Per bug #15847 from Feike Steenbergen. This is a longstanding misbehavior, but it's only worth worrying about when there are more appendrel children than we've historically considered wise to use. So I'm not going to take the risk of back-patching this. Discussion: https://postgr.es/m/15847-ea3734094bf8ae61@postgresql.org
* Avoid spurious deadlocks when upgrading a tuple lockAlvaro Herrera2019-06-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When two (or more) transactions are waiting for transaction T1 to release a tuple-level lock, and transaction T1 upgrades its lock to a higher level, a spurious deadlock can be reported among the waiting transactions when T1 finishes. The simplest example case seems to be: T1: select id from job where name = 'a' for key share; Y: select id from job where name = 'a' for update; -- starts waiting for X Z: select id from job where name = 'a' for key share; T1: update job set name = 'b' where id = 1; Z: update job set name = 'c' where id = 1; -- starts waiting for X T1: rollback; At this point, transaction Y is rolled back on account of a deadlock: Y holds the heavyweight tuple lock and is waiting for the Xmax to be released, while Z holds part of the multixact and tries to acquire the heavyweight lock (per protocol) and goes to sleep; once X releases its part of the multixact, Z is awakened only to be put back to sleep on the heavyweight lock that Y is holding while sleeping. Kaboom. This can be avoided by having Z skip the heavyweight lock acquisition. As far as I can see, the biggest downside is that if there are multiple Z transactions, the order in which they resume after X finishes is not guaranteed. Backpatch to 9.6. The patch applies cleanly on 9.5, but the new tests don't work there (because isolationtester is not smart enough), so I'm not going to risk it. Author: Oleksii Kliukin Discussion: https://postgr.es/m/B9C9D7CD-EB94-4635-91B6-E558ACEC0EC3@hintbits.com
* Mark ReplicationSlotCtl as PGDLLIMPORT.Tom Lane2019-06-13
| | | | | | | | | | | | | Also MyReplicationSlot, in branches where it wasn't already. This was discussed in the thread that resulted in c572599c6, but for some reason nobody pulled the trigger. Now that we have another request for the same thing, we should just do it. Craig Ringer Discussion: https://postgr.es/m/CAMsr+YFTsq-86MnsNng=mPvjjh5EAbzfMK0ptJPvzyvpFARuRg@mail.gmail.com Discussion: https://postgr.es/m/345138875.20190611151943@cybertec.at
* Fix double-word typosAlvaro Herrera2019-06-13
| | | | | Discussion: https://postgr.es/m/20190612184527.GA24266@alvherre.pgsql Reviewed-by: Michaël Paquier
* Fix incorrect printing of queries with duplicated join names.Tom Lane2019-06-12
| | | | | | | | | | | | | | | | | Given a query in which multiple JOIN nodes used the same alias (which'd necessarily be in different sub-SELECTs), ruleutils.c would assign the JOIN nodes distinct aliases for clarity ... but then it forgot to print the modified aliases when dumping the JOIN nodes themselves. This results in a dump/reload hazard for views, because the emitted query is flat-out incorrect: Vars will be printed with table names that have no referent. This has been wrong for a long time, so back-patch to all supported branches. Philip Dubé Discussion: https://postgr.es/m/CY4PR2101MB080246F2955FF58A6ED1FEAC98140@CY4PR2101MB0802.namprd21.prod.outlook.com
* Fix ALTER COLUMN TYPE failure with a partial exclusion constraint.Tom Lane2019-06-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ATExecAlterColumnType failed to consider the possibility that an index that needs to be rebuilt might be a child of a constraint that needs to be rebuilt. We missed this so far because usually a constraint index doesn't have a direct dependency on its table, just on the constraint object. But if there's a WHERE clause, then dependency analysis of the WHERE clause results in direct dependencies on the column(s) mentioned in WHERE. This led to trying to drop and rebuild both the constraint and its underlying index. In v11/HEAD, we successfully drop both the index and the constraint, and then try to rebuild both, and of course the second rebuild hits a duplicate-index-name problem. Before v11, it fails with obscure messages about a missing relation OID, due to trying to drop the index twice. This is essentially the same kind of problem noted in commit 20bef2c31: the possible dependency linkages are broader than what ATExecAlterColumnType was designed for. It was probably OK when written, but it's certainly been broken since the introduction of partial exclusion constraints. Fix by adding an explicit check for whether any of the indexes-to-be-rebuilt belong to any of the constraints-to-be-rebuilt, and ignoring any that do. In passing, fix a latent bug introduced by commit 8b08f7d48: in get_constraint_index() we must "continue" not "break" when rejecting a relation of a wrong relkind. This is harmless today because we don't expect that code path to be taken anyway; but if there ever were any relations to be ignored, the existing coding would have an extremely undesirable dependency on the order of pg_depend entries. Also adjust a couple of obsolete comments. Per bug #15835 from Yaroslav Schekin. Back-patch to all supported branches. Discussion: https://postgr.es/m/15835-32d9b7a76c06a7a9@postgresql.org
* Fix handling of COMMENT for domain constraintsMichael Paquier2019-06-12
| | | | | | | | | | | | | | | | | | | | For a non-superuser, changing a comment on a domain constraint was leading to a cache lookup failure as the code tried to perform the ownership lookup on the constraint OID itself, thinking that it was a type, but this check needs to happen on the type the domain constraint relies on. As the type a domain constraint relies on can be guessed directly based on the constraint OID, first fetch its type OID and perform the ownership on it. This is broken since 7eca575, which has split the handling of comments for table constraints and domain constraints, so back-patch down to 9.5. Reported-by: Clemens Ladisch Author: Daniel Gustafsson, Michael Paquier Reviewed-by: Álvaro Herrera Discussion: https://postgr.es/m/15833-808e11904835d26f@postgresql.org Backpatch-through: 9.5
* Fix conversion of JSON strings to JSON output columns in json_to_record().Tom Lane2019-06-11
| | | | | | | | | | | | | | | | | | | | | | | | | json_to_record(), when an output column is declared as type json or jsonb, should emit the corresponding field of the input JSON object. But it got this slightly wrong when the field is just a string literal: it failed to escape the contents of the string. That typically resulted in syntax errors if the string contained any double quotes or backslashes. jsonb_to_record() handles such cases correctly, but I added corresponding test cases for it too, to prevent future backsliding. Improve the documentation, as it provided only a very hand-wavy description of the conversion rules used by these functions. Per bug report from Robert Vollmert. Back-patch to v10 where the error was introduced (by commit cf35346e8). Note that PG 9.4 - 9.6 also get this case wrong, but differently so: they feed the de-escaped contents of the string literal to json[b]_in. That behavior is less obviously wrong, so possibly it's being depended on in the field, so I won't risk trying to make the older branches behave like the newer ones. Discussion: https://postgr.es/m/D6921B37-BD8E-4664-8D5F-DB3525765DCD@vllmrt.net
* Don't access catalogs to validate GUCs when not connected to a DB.Andres Freund2019-06-10
| | | | | | | | | | | | | | | | | | | | | Vignesh found this bug in the check function for default_table_access_method's check hook, but that was just copied from older GUCs. Investigation by Michael and me then found the bug in further places. When not connected to a database (e.g. in a walsender connection), we cannot perform (most) GUC checks that need database access. Even when only shared tables are needed, unless they're nailed (c.f. RelationCacheInitializePhase2()), they cannot be accessed without pg_class etc. being present. Fix by extending the existing IsTransactionState() checks to also check for MyDatabaseOid. Reported-By: Vignesh C, Michael Paquier, Andres Freund Author: Vignesh C, Andres Freund Discussion: https://postgr.es/m/CALDaNm1KXK9gbZfY-p_peRFm_XrBh1OwQO1Kk6Gig0c0fVZ2uw%40mail.gmail.com Backpatch: 9.4-
* tableam: Fix index_build_range_scan parameter name.Robert Haas2019-06-10
| | | | | | | | | | All of the other code thinks that the 8th parameter is the number of blocks, but this declaration thinks that it's the ending block number. Repair this inconsistency. Patch by me, reviewed by Andres Freund. Discussion: http://postgr.es/m/CA+TgmoY49ManQWnJtiwkuytXBkmyTuDFqb74Pr4Zn2Nq9TuNBQ@mail.gmail.com
* Make pg_dump emit ATTACH PARTITION instead of PARTITION OF (reprise)Alvaro Herrera2019-06-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Using PARTITION OF can result in column ordering being changed from the database being dumped, if the partition uses a column layout different from the parent's. It's not pg_dump's job to editorialize on table definitions, so this is not acceptable; back-patch all the way back to pg10, where partitioned tables where introduced. This change also ensures that partitions end up in the correct tablespace, if different from the parent's; this is an oversight in ca4103025dfe (in pg12 only). Partitioned indexes (in pg11) don't have this problem, because they're already created as independent indexes and attached to their parents afterwards. This change also has the advantage that the partition is restorable from the dump (as a standalone table) even if its parent table isn't restored. The original commits (3b23552ad8bb in branch master) failed to cover subsidiary column elements correctly, such as NOT NULL constraint and CHECK constraints, as reported by Rushabh Lathia (initially as a failure to restore serial columns). They were reverted. This recapitulation commit fixes those problems. Add some pg_dump tests to verify these things more exhaustively, including constraints with legacy-inheritance tables, which were not tested originally. In branches 10 and 11, add a local constraint to the pg_dump test partition that was added by commit 2d7eeb1b1492 to master. Author: Álvaro Herrera, David Rowley Reviewed-by: Álvaro Herrera Discussion: https://postgr.es/m/CAKJS1f_1c260nOt_vBJ067AZ3JXptXVRohDVMLEBmudX1YEx-A@mail.gmail.com Discussion: https://postgr.es/m/20190423185007.GA27954@alvherre.pgsql Discussion: https://postgr.es/m/CAGPqQf0iQV=PPOv2Btog9J9AwOQp6HmuVd6SbGTR_v3Zp2XT1w@mail.gmail.com
* MSVC: Reconcile clean.bat with PostgreSQL 12 work.Noah Misch2019-06-09
|
* Reconcile nodes/*funcs.c with PostgreSQL 12 work.Noah Misch2019-06-09
| | | | | | One would have needed out-of-tree code to observe the defects. Remove unreferenced fields instead of completing their support functions. Since in-tree code can't reach _readIntoClause(), no catversion bump.
* Switch position of some declarations in libpq.hMichael Paquier2019-06-09
| | | | | | | | This makes the header more consistent with the surroundings, with declarations associated to a given file grouped together. Author: Daniel Gustafsson Discussion: https://postgr.es/m/20190608012439.GB7228@paquier.xyz
* Stop using spelling "nonexistant".Noah Misch2019-06-08
| | | | | The documentation used "nonexistent" exclusively, and the source tree used it three times as often as "nonexistant".
* Update stale comments, and fix comment typos.Noah Misch2019-06-08
|
* Fix assorted inconsistencies.Amit Kapila2019-06-08
| | | | | | | | | | There were a number of issues in the recent commits which include typos, code and comments mismatch, leftover function declarations. Fix them. Reported-by: Alexander Lakhin Author: Alexander Lakhin, Amit Kapila and Amit Langote Reviewed-by: Amit Kapila Discussion: https://postgr.es/m/ef0c0232-0c1d-3a35-63d4-0ebd06e31387@gmail.com
* Move be-gssapi-common.h into src/include/libpq/Michael Paquier2019-06-08
| | | | | | | | | | | The file has been introduced in src/backend/libpq/ as of b0b39f72, but all backend-side headers of libpq are located in src/include/libpq/. Note that the identification path on top of the file referred to src/include/libpq/ from the start. Author: Michael Paquier Reviewed-by: Stephen Frost Discussion: https://postgr.es/m/20190607043415.GE1736@paquier.xyz
* Improve some comments in pg_checksums about the needed clean shutdownMichael Paquier2019-06-07
| | | | | | | | It was not clear from the code why it is necessary. And we need a clean shutdown to avoid random checksum failures caused by torn pages. Author: Masahiko Sawada Discussion: https://postgr.es/m/CAD21AoDum5MbAb7F=pa9dOD1W2tukuDMPzWT7NjZceNoWB_6Qw@mail.gmail.com
* Fix default_tablespace usage for partitioned tablesAlvaro Herrera2019-06-07
| | | | | | | | | | | In commit 87259588d0ab I (Álvaro) tried to rationalize the determination of tablespace to use for partitioned tables, but failed to handle the default_tablespace case. Repair and add proper tests. Author: Amit Langote, Rushabh Lathia Reported-by: Rushabh Lathia Reviewed-by: Amit Langote, Álvaro Herrera Discussion: https://postgr.es/m/CAGPqQf0cYjm1=rjxk_6gU0SjUS70=yFUAdCJLwWzh9bhNJnyVg@mail.gmail.com
* Fix inconsistency in comments atop ExecParallelEstimate.Amit Kapila2019-06-07
| | | | | | | | | | | | | When this code was initially introduced in commit d1b7c1ff, the structure used was SharedPlanStateInstrumentation, but later when it got changed to Instrumentation structure in commit b287df70, we forgot to update the comment. Reported-by: Wu Fei Author: Wu Fei Reviewed-by: Amit Kapila Backpatch-through: 9.6 Discussion: https://postgr.es/m/52E6E0843B9D774C8C73D6CF64402F0562215EB2@G08CNEXMBPEKD02.g08.fujitsu.local
* Fix message styleAlvaro Herrera2019-06-06
| | | | | | | Mark one message not for translation, and prefer "cannot" over "may not", per commentary from Robert Haas. Discussion: https://postgr.es/m/20190430145813.GA29872@alvherre.pgsql
* Add forgotten translatable string in pg_checksums.cMichael Paquier2019-06-06
| | | | | | | Oversight in commit 280e5f1. Author: Kyotaro Horiguchi Discussion: https://postgr.es/m/20190606.200612.110313249.horikyota.ntt@gmail.com
* pg_waldump: Fix invalid option handlingPeter Eisentraut2019-06-06
| | | | | | | | | | | Previously, running pg_waldump with an invalid option (pg_waldump --foo) would print the help output and exit successfully. This was because it tried to process the option letter '?' as a normal option, but that letter is used by getopt() to report an invalid option. To fix, process help and version options separately, like we do everywhere else. Also add a basic test suite for pg_waldump and run the basic option handling tests, which would have caught this.
* Fix confusion on different kinds of slots in IndexOnlyScans.Heikki Linnakangas2019-06-06
| | | | | | | | | | We used the same slot to store a tuple from the index, and to store a tuple from the table. That's not OK. It worked with the heap, because heapam_getnextslot() stores a HeapTuple to the slot, and doesn't care how large the tts_values/nulls arrays are. But when I played with a toy table AM implementation that used a virtual tuple, it caused memory overruns. In the passing, tidy up comments on the ioss_PscanLen fields.
* Fix confusing NOTICE text in REINDEX CONCURRENTLYDavid Rowley2019-06-05
| | | | | | | | | | | | | | | When performing REINDEX TABLE CONCURRENTLY, if all of the table's indexes could not be reindexed, a NOTICE message claimed that the table had no indexes. This was confusing, so let's change the NOTICE text to something less confusing. In passing, also mention in the comment before ReindexRelationConcurrently that materialized views are supported too and also explain what the return value of the function means. Author: Ashwin Agrawal Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/CALfoeithHvi13p_VyR8kt9o6Pa7Z=Smi6Nfc2anHnQx5Lj8bTQ@mail.gmail.com
* Fix incorrect index behavior in COPY FROM with partitioned tablesDavid Rowley2019-06-05
| | | | | | | | | | | | | | | | 86b85044e rewrote how COPY FROM works to allow multiple tuple buffers to exist to once thus allowing multi-inserts to be used in more cases with partitioned tables. That commit neglected to update the estate's es_result_relation_info when flushing the insert buffer to the partition making it possible for the index tuples to be added into an index on the wrong partition. Fix this and also add an Assert in ExecInsertIndexTuples to help ensure that we never make this mistake again. Reported-by: Haruka Takatsuka Author: Ashutosh Sharma Discussion: https://postgr.es/m/15832-b1bf336a4ee246b5@postgresql.org
* Rework code using list_delete_cell() in MergeAttributesMichael Paquier2019-06-05
| | | | | | | | | | | | | | | When merging two attributes, we are sure that at least one remains. However, when deleting one element in the attribute list we may finish with an empty list returned as NIL by list_delete_cell(), but the code failed to track that, which is not project-like. Adjust the call so as we check for an empty list, and make use of it in an assertion. This has been introduced by e7b3349, when adding support for CREATE TABLE OF. Author: Mark Dilger Reviewed-by: Álvaro Herrera, Michael Paquier Discussion: https://postgr.es/m/CAE-h2TpPDqSWgOvfvSziOaMngMPwW+QZcmPpY8hQ_KOJ2+3hXQ@mail.gmail.com
* Add command column to pg_stat_progress_create_indexPeter Eisentraut2019-06-04
| | | | | | | This allows determining which command is running, similar to pg_stat_progress_cluster. Discussion: https://www.postgresql.org/message-id/flat/f0e56b3b-74b7-6cbc-e207-a5ed6bee18dc%402ndquadrant.com
* Fix some typos and inconsistencies in tableam.hMichael Paquier2019-06-04
| | | | | | | | | | | The defined callback definitions have been using references to heap for a couple of variables and comments. This makes the whole interface more consistent by using "table" which is more generic. A variable storing index information was misspelled as well. Author: Michael Paquier Discussion: https://postgr.es/m/20190601190946.GB1905@paquier.xyz
* Fix unsafe memory management in CloneRowTriggersToPartition().Tom Lane2019-06-03
| | | | | | | | | | | | | It's not really supported to call systable_getnext() in a different memory context than systable_beginscan() was called in, and it's *definitely* not safe to do so and then reset that context between calls. I'm not very clear on how this code survived CLOBBER_CACHE_ALWAYS testing ... but Alexander Lakhin found a case that would crash it pretty reliably. Per bug #15828. Fix, and backpatch to v11 where this code came in. Discussion: https://postgr.es/m/15828-f6ddd7df4852f473@postgresql.org
* Update SQL conformance information about JSON pathPeter Eisentraut2019-06-03
| | | | Reviewed-by: Oleg Bartunov <obartunov@postgrespro.ru>
* Fix typos in various placesMichael Paquier2019-06-03
| | | | | | Author: Andrea Gelmini Reviewed-by: Michael Paquier, Justin Pryzby Discussion: https://postgr.es/m/20190528181718.GA39034@glet
* Fix some issues and improve psql completion for access methodsMichael Paquier2019-06-03
| | | | | | | | | | | | | The following issues have been spotted: - CREATE INDEX .. USING suggests both index and table AMs, but it should consider only index AMs. - CREATE TABLE .. USING has no completion support. USING was not being included in the completion list where it should, and follow-up suggestions for table AMs have been missing as well. - CREATE ACCESS METHOD .. TYPE suggests only INDEX, with TABLE missing. Author: Michael Paquier Discussion: https://postgr.es/m/20190601191007.GC1905@paquier.xyz
* Make cpluspluscheck more portable.Tom Lane2019-06-02
| | | | | | | | | | | | | Teach it to scrape -I and -D switches from CPPFLAGS in Makefile.global. This is useful for testing on, eg, FreeBSD, where you won't get far without "-I/usr/local/include". Also, expand the set of blacklisted-for-unportability atomics headers, based on noting that arch-x86.h fails to compile on an ARM box. The other ones I'd omitted seem to compile all right on architectures they don't belong to, but that's surely too shaky to rely on. Let's do like we did for the src/include/port/ headers, and ignore all except the variant that's pulled in by the arch-independent header.
* Clean up PL/Perl's handling of the _() macro.Tom Lane2019-06-02
| | | | | | | | | | | | | | | | | | | | | | | | | | Perl likes to redefine the _() macro: #ifdef CAN_PROTOTYPE #define _(args) args #else ... There was lots not to like about the way we dealt with this before: 1. Instead of taking care of the conflict centrally in plperl.h, we expected every one of its ever-growing number of includers to do so. This is duplicative and error-prone in itself, plus it means that plperl.h fails to meet the expectation of being compilable standalone, resulting in macro-redefinition warnings in cpluspluscheck. 2. We left _() with its Perl definition, meaning that if someone tried to use it in any Perl-related extension, it would silently fail to provide run-time translation. I don't see any live bugs of this ilk, but it's clearly a hard-to-notice bug waiting to happen. So fix that by centralizing the cleanup logic, making it match what we're already doing for other macro conflicts with Perl. Since we only expect plperl.h to be included by extensions not core code, we should redefine _() as dgettext() not gettext().
* worker_spi needs a .gitignore file now.Tom Lane2019-06-02
|
* Un-break ecpg tests for Windows.Tom Lane2019-06-02
| | | | | | | | | | Declaring a function "inline" still doesn't work with Windows compilers (C99? what's that?), unless the macro provided by pg_config.h is in-scope, which it is not in our ECPG test programs. So the workaround I tried to use in commit 7640f9312 doesn't work for Windows. Revert the change in printf_hack.h, and instead just blacklist that file in cpluspluscheck --- since it's a not-installed test file, we don't really need to verify its C++ cleanliness anyway.
* Increase test coverage for worker_spi by ∞%Alvaro Herrera2019-06-02
| | | | | | | | | | | This test module was not getting invoked, other than at compile time, limiting its usefulness -- and keeping its coverage at 0%. Add a minimal regression test to ensure it runs on make check-world; this makes it 92% covered (line-wise), which seems sufficient. Author: Álvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/20190529193256.GA17603@alvherre.pgsql
* Improve coverage of cpluspluscheck.Tom Lane2019-05-31
| | | | | | | | | | | | | Formerly, cpluspluscheck was only meant to examine headers that we thought of as exported --- but its notion of what we export was well behind the times. Let's just make it check *all* .h files, except for a well-defined blacklist, instead. While at it, improve its ability to use a C++ compiler other than g++, by scraping the CXX setting from Makefile.global and making it possible to override the warning options used (per suggestion from Andres Freund). Discussion: https://postgr.es/m/b517ec3918d645eb950505eac8dd434e@gaz-is.ru
* Integrate cpluspluscheck into build system.Andres Freund2019-05-31
| | | | | | | | Previously cpluspluscheck wouldn't work in vpath builds, this commit fixes that. To make it easier to invoke, there's a top-level cpluspluscheck target. Discussion: https://postgr.es/20190530220244.kiputcbl4gkl2oo6@alap3.anarazel.de
* Fix incorrect parameter name in commentDavid Rowley2019-05-31
| | | | | Author: Antonin Houska Discussion: https://postgr.es/m/22370.1559293357@localhost
* Adjust ecpg expected-results files for commit 7640f9312.Tom Lane2019-05-31
| | | | | Mea culpa for not rechecking check-world at the last step :-( Per buildfarm.
* Fix C++ incompatibilities in ecpg/preproc/ header files.Tom Lane2019-05-31
| | | | | | | There's probably no need to back-patch this, since it seems unlikely that anybody would be inserting C++ code into ecpg's preprocessor. Discussion: https://postgr.es/m/b517ec3918d645eb950505eac8dd434e@gaz-is.ru
* Fix C++ incompatibilities in plpgsql's header files.Tom Lane2019-05-31
| | | | | | | | | | | Rename some exposed parameters so that they don't conflict with C++ reserved words. Back-patch to all supported versions. George Tarasov Discussion: https://postgr.es/m/b517ec3918d645eb950505eac8dd434e@gaz-is.ru
* Fix assorted header files that failed to compile standalone.Tom Lane2019-05-31
| | | | | | | | | | | | | | | | | | | We have a longstanding project convention that all .h files should be includable with no prerequisites other than postgres.h. This is tested/relied-on by cpluspluscheck. However, cpluspluscheck has not historically been applied to most headers outside the src/include tree, with the predictable consequence that some of them don't work. Fix that, usually by adding missing #include dependencies. The change in printf_hack.h might require some explanation: without it, my C++ compiler whines that the function is unused. There's not so many call sites that "inline" is going to cost much, and besides all the callers are in test code that we really don't care about the size of. There's no actual bugs being fixed here, so I see no need to back-patch. Discussion: https://postgr.es/m/b517ec3918d645eb950505eac8dd434e@gaz-is.ru
* Make our perfect hash functions be valid C++.Tom Lane2019-05-31
| | | | | | | | | While C is happy to cast "const void *" to "const unsigned char *" silently, C++ insists on an explicit cast. Since we put these functions into header files, cpluspluscheck whines about that. Add the cast to pacify it. Discussion: https://postgr.es/m/b517ec3918d645eb950505eac8dd434e@gaz-is.ru
* Fix double-phrase typo in messageAlvaro Herrera2019-05-31
| | | | New in 147e3722f7e5.
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-04 16:08:02 +0000