aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
...
* Add missing 'the' to pgtrgm.sgmlAlexander Korotkov2020-11-15
| | | | | Author: Erik Rijkers Discussion: https://postgr.es/m/159fba265fe7c37334640fdc0444cc4b%40xs4all.nl
* Fix alphabetic ordering in typedefs.listAlexander Korotkov2020-11-15
|
* Handle equality operator in contrib/pg_trgmAlexander Korotkov2020-11-15
| | | | | | | | | | Obviously, in order to equality operator be satisfiable, target string must contain all the trigrams of the search string. On this base, we implement equality operator in GiST/GIN indexes with recheck. Discussion: https://postgr.es/m/CAOBaU_YWwtT7tdggtROacjdOdeYHCz-tmSwuC-j-TOG-g97J0w%40mail.gmail.com Author: Julien Rouhaud Reviewed-by: Tom Lane, Alexander Korotkov, Georgios Kokolatos, Erik Rijkers
* Provide the OR REPLACE option for CREATE TRIGGER.Tom Lane2020-11-14
| | | | | | | | | | | | | | | | | | This is mostly straightforward. However, we disallow replacing constraint triggers or changing the is-constraint property; perhaps that can be added later, but the complexity versus benefit tradeoff doesn't look very good. Also, no special thought is taken here for whether replacing an existing trigger should result in changes to queued-but-not-fired trigger actions. We just document that if you're surprised by the results, too bad, don't do that. (Note that any such pending trigger activity would have to be within the current session.) Takamichi Osumi, reviewed at various times by Surafel Temesgen, Peter Smith, and myself Discussion: https://postgr.es/m/0DDF369B45A1B44B8A687ED43F06557C010BC362@G01JPEXMBYT03
* Doc: improve partitioning discussion in ddl.sgml.Tom Lane2020-11-14
| | | | | | | | | | | | | | | This started with the intent to explain that range upper bounds are exclusive, which previously you could only find out by reading the CREATE TABLE man page. But I soon found that section 5.11 really could stand a fair amount of editorial attention. It's apparently been revised several times without much concern for overall flow, nor careful copy-editing. Back-patch to v11, which is as far as the patch goes easily. Per gripe from Edson Richter. Thanks to David Johnston for review. Discussion: https://postgr.es/m/DM6PR13MB3988736CF8F5DC5720440231CFE60@DM6PR13MB3988.namprd13.prod.outlook.com
* Fix some typosMichael Paquier2020-11-14
| | | | | Author: Daniel Gustafsson Discussion: https://postgr.es/m/C36ADFDF-D09A-4EE5-B186-CB46C3653F4C@yesql.se
* Support negative indexes in split_part().Tom Lane2020-11-13
| | | | | | | | | | | | | | This provides a handy way to get, say, the last field of the string. Use of a negative index in this way has precedent in the nearby left() and right() functions. The implementation scans the string twice when N < -1, but it seems likely that N = -1 will be the huge majority of actual use cases, so I'm not really excited about adding complexity to avoid that. Nikhil Benesch, reviewed by Jacob Champion; cosmetic tweakage by me Discussion: https://postgr.es/m/cbb7f861-6162-3a51-9823-97bc3aa0b638@gmail.com
* Remove another test that doesn't work on Windows.Heikki Linnakangas2020-11-13
| | | | | | Apparently double-quotes are not allowed in filenames on Windows, either. Per buildfarm.
* doc: clarify where to find pg_type_d.h (PG 11+) and pg_type.hBruce Momjian2020-11-12
| | | | | | | | | | These files are in compiled directories and install directories. Reported-by: e.indrupskaya@postgrespro.ru Discussion: https://postgr.es/m/160379609706.24746.7506163279454026608@wrigleys.postgresql.org Backpatch-through: 9.5
* docs: mention that expression indexes need analyzeBruce Momjian2020-11-12
| | | | | | | | | | | | | Expression indexes can't benefit from pre-computed statistics on columns. Reported-by: Nikolay Samokhvalov Discussion: https://postgr.es/m/CANNMO++5rw9RDA=p40iMVbMNPaW6O=S0AFzTU=KpYHRpCd1voA@mail.gmail.com Author: Nikolay Samokhvalov, modified Backpatch-through: 9.5
* change wire protocol data type for history file contentBruce Momjian2020-11-12
| | | | | | | | | | | | | This was marked as BYTEA, but is more like TEXT, which is how we already pass the history timeline file name. Internally, we don't do any encoding or bytea escape handling, but TEXT seems closest. This should cause no behavioral change. Reported-by: Brar Piening Discussion: https://postgr.es/m/6a1b9cd9-17e3-df67-be55-86102af6bdf5@gmx.de Backpatch-through: master
* Remove tests that don't work on Windows.Heikki Linnakangas2020-11-12
| | | | | | | | | | On Windows, a filename cannot contain backslashes, because a backslash is used directory separator. Remove tests I added in commit 9c4f5192f that tried to do that. We could perhaps use a SKIP block to only skip them on Windows, but I'm not sure how exactly to formulate that, so just remove the tests to make the buildfarm green again. Per buildfarm.
* pg_trgm: fix crash in 2-item picksplitAndrew Gierth2020-11-12
| | | | | | | | | | | | | | | | | | | | Whether from size overflow in gistSplit or from secondary splits, picksplit is (rarely) called with exactly two items to split. Formerly, due to special-case handling of the last item, this would lead to access to an uninitialized cache entry; prior to PG 13 this might have been harmless or at worst led to an incorrect union datum, but in 13 onwards it can cause a backend crash from using an uninitialized pointer. Repair by removing the special case, which was deemed not to have been appropriate anyway. Backpatch all the way, because this bug has existed since pg_trgm was added. Per report on IRC from user "ftzdomino". Analysis and testing by me, patch from Alexander Korotkov. Discussion: https://postgr.es/m/87k0usfdxg.fsf@news-spur.riddles.org.uk
* Allow pg_rewind to use a standby server as the source system.Heikki Linnakangas2020-11-12
| | | | | | | | | | | | | | Using a hot standby server as the source has not been possible, because pg_rewind creates a temporary table in the source system, to hold the list of file ranges that need to be fetched. Refactor it to queue up the file fetch requests in pg_rewind's memory, so that the temporary table is no longer needed. Also update the logic to compute 'minRecoveryPoint' correctly, when the source is a standby server. Reviewed-by: Kyotaro Horiguchi, Soumyadeep Chakraborty Discussion: https://www.postgresql.org/message-id/0c5b3783-af52-3ee5-f8fa-6e794061f70d%40iki.fi
* Clean up optional rules in grammarPeter Eisentraut2020-11-12
| | | | | | | | | Various rules for optional keywords contained unnecessary rules and type declarations. Remove those, thus making the output a tiny bit smaller. Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi> Discussion: https://www.postgresql.org/message-id/flat/e9eed669-e32d-6919-fed4-acc0daea857b%40enterprisedb.com
* Fix typo in contrib/pg_trgm/pg_trgm--1.4--1.5.sqlAlexander Korotkov2020-11-12
| | | | Backpatch-through: 13
* Use standard SIGHUP and SIGTERM handlers in walreceiver.Fujii Masao2020-11-12
| | | | | | | | | | | | | | | | | Commit 1e53fe0e70 changed background processes so that they use standard SIGHUP handler. Like that, this commit makes walreceiver use standard SIGHUP and SIGTERM handlers, to simplify the code. As the side effect of this commit, walreceiver can wake up and process the configuration files promptly when receiving SIGHUP. Because the standard SIGHUP handler sets the latch. On the other hand, previously there could be a time lag between the receipt of SIGHUP and the process of configuration files since the dedicated handler didn't set the latch. Author: Bharath Rupireddy, tweaked by Fujii Masao Reviewed-by: Kyotaro Horiguchi, Fujii Masao Discussion: https://postgr.es/m/CALj2ACXPorUqePswDtOeM_s82v9RW32E1fYmOPZ5NuE+TWKj_A@mail.gmail.com
* Fix name of the macro for getting signature length trgm_gist.cAlexander Korotkov2020-11-12
| | | | | | | | | 911e702077 has introduced the opclass parameters including signature length for a set of GiST opclasses. Due to copy-pasting, macro for getting the signature length in trgm_gist.c was named LTREE_GET_ASIGLEN(). Fix that by renaming this macro to just GET_SIGLEN(). Backpatch-through: 13
* pg_stat_statements: track number of rows processed by REFRESH MATERIALIZED VIEW.Fujii Masao2020-11-12
| | | | | | | | | | | | | | | | | | | | Commit 6023b7ea71 allowed pg_stat_statements to track the number of rows retrieved or affected by some utility commands including CREATE MATERIALIZED VIEW. However it did not track the rowcount of REFRESH MATERIALIZED VIEW. This commit allows pg_stat_statements to track that. To track that, this commit changes the query completion for REFRESH MATERIALIZED VIEW so that it saves the rowcount. But note that the rowcount is still not displayed in the command completion tag output. That is, the display_rowcount flag of CMDTAG_REFRESH_MATERIALIZED_VIEW command tag is left false in cmdtaglist.h. Otherwise, the change of completion tag output might break applications using it. Author: Katsuragi Yuta, Seino Yuki Reviewed-by: Fujii Masao Discussion: https://postgr.es/m/71f6bc72f8bbaa06e701f8bd2562c347@oss.nttdata.com Discussion: https://postgr.es/m/aadbfba9-e4bb-9531-6b3a-d13c31c8f4fe@oss.nttdata.com
* Remove useless SHA256 initialization when not using backup manifestsMichael Paquier2020-11-12
| | | | | | | | | | | | | | | | | | | | Attempting to take a base backup with Postgres linking to a build of OpenSSL with FIPS enabled currently fails with or even without a backup manifest requested because of this mandatory SHA256 initialization used for the manifest file itself. However, there is no need to do this initialization at all if backup manifests are not needed because there is no data to append to the manifest. Note that being able to use backup manifests with OpenSSL+FIPS requires a switch of the SHA2 implementation to use EVP, which would cause an ABI breakage so this cannot be backpatched to 13 as it has been already released, but at least avoiding this SHA256 initialization gives users the possibility to take a base backup even when specifying --no-manifest with pg_basebackup. Author: Michael Paquier Discussion: https://postgr.es/m/20201110020014.GE1887@paquier.xyz Backpatch-through: 13
* Remove duplicate code in brin_memtuple_initializeTomas Vondra2020-11-11
| | | | | | | | | | Commit 8bf74967dab moved some of the code from brin_new_memtuple to brin_memtuple_initialize, but this resulted in some of the code being duplicate. Fix by removing the duplicate lines and backpatch to 10. Author: Tomas Vondra Backpatch-through: 10 Discussion: https://postgr.es/m/5eb50c97-9a8e-b691-8c40-1b2a55611c4c%40enterprisedb.com
* Fix some stray whitespace in parser filesPeter Eisentraut2020-11-11
|
* Remove line missed in previous commitMagnus Hagander2020-11-11
|
* Remove vacuumdb --analyze-in-stages from pg_upgrade testsMagnus Hagander2020-11-11
| | | | | | | | This step was only there to test the script when we generated those, but commit 8f113698b6 removed those scripts, so it's not needed anymore. Reported-By: Peter Eisentraut Discussion: https://postgr.es/m/ea403f46-2b33-a7de-618e-9cab35a698c8@enterprisedb.com
* Add pg_nodiscard decorations to some functionsPeter Eisentraut2020-11-11
| | | | | | | | Especially for the list API such as lappend() forgetting to assign the return value is a common problem. Reviewed-by: Michael Paquier <michael@paquier.xyz> Discussion: https://www.postgresql.org/message-id/flat/e3753562-99cd-b65f-5aca-687dfd1ec2fc@2ndquadrant.com
* Add pg_nodiscard function declaration specifierPeter Eisentraut2020-11-11
| | | | | | | | | | pg_nodiscard means the compiler should warn if the result of a function call is ignored. The name "nodiscard" is chosen in alignment with (possibly future) C and C++ standards. It maps to the GCC attribute warn_unused_result. Reviewed-by: Michael Paquier <michael@paquier.xyz> Discussion: https://www.postgresql.org/message-id/flat/e3753562-99cd-b65f-5aca-687dfd1ec2fc@2ndquadrant.com
* Fix cases of discarding result from list API functionsPeter Eisentraut2020-11-11
| | | | | | | | | | | | Two cases violated list APIs by throwing away the return value. While the code was technically correct, it relied on internal knowledge of the list implementation, and the code wasn't really gaining anything that way. It is planned to make this a compiler warning in the future, so just fix these cases by assigning the return value properly. Reviewed-by: Michael Paquier <michael@paquier.xyz> Discussion: https://www.postgresql.org/message-id/flat/e3753562-99cd-b65f-5aca-687dfd1ec2fc@2ndquadrant.com
* Fix and simplify some usages of TimestampDifference().Tom Lane2020-11-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce TimestampDifferenceMilliseconds() to simplify callers that would rather have the difference in milliseconds, instead of the select()-oriented seconds-and-microseconds format. This gets rid of at least one integer division per call, and it eliminates some apparently-easy-to-mess-up arithmetic. Two of these call sites were in fact wrong: * pg_prewarm's autoprewarm_main() forgot to multiply the seconds by 1000, thus ending up with a delay 1000X shorter than intended. That doesn't quite make it a busy-wait, but close. * postgres_fdw's pgfdw_get_cleanup_result() thought it needed to compute microseconds not milliseconds, thus ending up with a delay 1000X longer than intended. Somebody along the way had noticed this problem but misdiagnosed the cause, and imposed an ad-hoc 60-second limit rather than fixing the units. This was relatively harmless in context, because we don't care that much about exactly how long this delay is; still, it's wrong. There are a few more callers of TimestampDifference() that don't have a direct need for seconds-and-microseconds, but can't use TimestampDifferenceMilliseconds() either because they do need microsecond precision or because they might possibly deal with intervals long enough to overflow 32-bit milliseconds. It might be worth inventing another API to improve that, but that seems outside the scope of this patch; so those callers are untouched here. Given the fact that we are fixing some bugs, and the likelihood that future patches might want to back-patch code that uses this new API, back-patch to all supported branches. Alexey Kondratov and Tom Lane Discussion: https://postgr.es/m/3b1c053a21c07c1ed5e00be3b2b855ef@postgrespro.ru
* doc: fix spelling "connction" to "connection"Bruce Momjian2020-11-10
| | | | | | | | | | Was wrong in commit 1a9388bd0f. Reported-by: Tom Lane, Justin Pryzby Discussion: https://postgr.es/m/20201102063333.GE22691@telsasoft.com Backpatch-through: 9.5
* Work around cross-version-upgrade issues created by commit 9e38c2bb5.Tom Lane2020-11-10
| | | | | | | | | | | | | Summarily changing the STYPE of regression-test aggregates that depend on array_append or array_cat is an issue for the buildfarm's cross-version-upgrade tests, because those aggregates (as defined in the back branches) now won't load into HEAD. Although this seems like only a minimal risk for genuine user-defined aggregates, we need to do something for the buildfarm. Hence, adjust the aggregate definitions, in both HEAD and the back branches. Discussion: https://postgr.es/m/1401824.1604537031@sss.pgh.pa.us Discussion: https://postgr.es/m/E1kaQ2c-0005lx-Eg@gemulon.postgresql.org
* pg_rewind: Fix thinko in parsing target WAL.Heikki Linnakangas2020-11-10
| | | | | | | | | | | It's entirely possible to see WAL for a relation that doesn't exist in the target anymore. That happens when the relation was dropped later. The refactoring in commit eb00f1d4b broke that case, by sanity-checking the file type in the target before checking the flag forwhether it exists there at all. I noticed this during manual testing. Modify the 001_basic.pl test so that it covers this case.
* Fix out of date commentMagnus Hagander2020-11-10
|
* Remove -o option to postmasterMagnus Hagander2020-11-10
| | | | | | | This option was declared obsolete many years ago. Reviewed-By: Tom Lane Discussion: https://postgr.es/m/CABUevEyOE=9CQwZm2j=vwP5+6OLCSoxn9pBjK8gyRdkTzMfqtQ@mail.gmail.com
* jit: Add support for LLVM 12.Andres Freund2020-11-09
| | | | | | | | | | | | | | | | | | LLVM 12, to be released in a few months, made some breaking changes to the Orc JIT interface. OrcV2 eventually will make it easier to support features like concurrent JIT compilation, but this commit only allows to compile against LLVM 12. This commit is a bit bigger than desirable. That partially is because the V2 interface is more granular than V1 interface, but also because I chose to make some minor changes to < LLVM 12 code to keep the code somewhat readable. The LLVM 12 support will need to be backpatched. I plan to do so after the patch stewed on the buildfarm for a few days. Author: Andres Freund Discussion: https://postgr.es/m/20201016011244.pmyvr3ee2gbzplq4@alap3.anarazel.de
* Doc: clarify data type behavior of COALESCE and NULLIF.Tom Lane2020-11-09
| | | | | | | After studying the code, NULLIF is a lot more subtle than you might have guessed. Discussion: https://postgr.es/m/160486028730.25500.15740897403028593550@wrigleys.postgresql.org
* Remove ineffective heapam CHECK_FOR_INTERRUPTS().Peter Geoghegan2020-11-09
| | | | | | | | | | | | Remove a CHECK_FOR_INTERRUPTS() call that could never actually handle an interrupt. We always have a heap page buffer lock at this point. Having a useless CHECK_FOR_INTERRUPTS() call is harmless but misleading. It is probably possible to work around the immediate problem by moving the CHECK_FOR_INTERRUPTS() to before the heap page buffer lock is acquired. That isn't enough to make the function responsive to interrupts, though. The index AM caller will still hold an exclusive buffer lock of its own.
* Ignore attempts to \gset into specially treated variables.Noah Misch2020-11-09
| | | | | | | | | | | | | | | If an interactive psql session used \gset when querying a compromised server, the attacker could execute arbitrary code as the operating system account running psql. Using a prefix not found among specially treated variables, e.g. every lowercase string, precluded the attack. Fix by issuing a warning and setting no variable for the column in question. Users wanting the old behavior can use a prefix and then a meta-command like "\set HISTSIZE :prefix_HISTSIZE". Back-patch to 9.5 (all supported versions). Reviewed by Robert Haas. Reported by Nick Cleaton. Security: CVE-2020-25696
* In security-restricted operations, block enqueue of at-commit user code.Noah Misch2020-11-09
| | | | | | | | | | | | | | | | | | Specifically, this blocks DECLARE ... WITH HOLD and firing of deferred triggers within index expressions and materialized view queries. An attacker having permission to create non-temp objects in at least one schema could execute arbitrary SQL functions under the identity of the bootstrap superuser. One can work around the vulnerability by disabling autovacuum and not manually running ANALYZE, CLUSTER, REINDEX, CREATE INDEX, VACUUM FULL, or REFRESH MATERIALIZED VIEW. (Don't restore from pg_dump, since it runs some of those commands.) Plain VACUUM (without FULL) is safe, and all commands are fine when a trusted user owns the target object. Performance may degrade quickly under this workaround, however. Back-patch to 9.5 (all supported versions). Reviewed by Robert Haas. Reported by Etienne Stalmans. Security: CVE-2020-25695
* Remove analyze_new_cluster script from pg_upgradeMagnus Hagander2020-11-09
| | | | | | | | | Since this script just runs vacuumdb anyway, remove the script and replace the instructions to run it with instructions to run vacuumdb directly. Reviewed-By: Michael Paquier Discussion: https://postgr.es/m/CABUevEwg5LDFzthhxzSj7sZGMiVsZe0VVNbzzwTQOHJ=rN7+5A@mail.gmail.com
* Remove incorrect %s in stringMagnus Hagander2020-11-09
| | | | | | | | | Appears to have been a copy/paste error in the original commit that moved the messages to fe_utils/. Author: Tang, Haiying <tanghy.fnst@cn.fujitsu.com> Backpatch-through: 13 Discussion: https://postgr.es/m/3321cbcea76d4d2c8320a05c19b9304a@G08CNEXMBPEKD05.g08.fujitsu.local
* doc: Add note about pg_settings and customized options into catalogs.sgml.Fujii Masao2020-11-09
| | | | | | | | | | The pg_settings view does not display customized options until the extension module that defines them has been loaded. This commit add the note about that behavior, into the docs. Author: John Naylor Reviewed-by: Tom Lane, Fujii Masao Discussion: https://postgr.es/m/CAFBsxsGsBZsG=cLM0Op5HFb2Ks6SzJrOc_eRO_jcKSNuqFRKnQ@mail.gmail.com
* Fix parsePGArray() error checking in pg_dump.Thomas Munro2020-11-09
| | | | | | | | | | | | | | | Coverity complained about a defect in commit 257836a7: Calling "parsePGArray" without checking return value (as is done elsewhere 11 out of 13 times). Fix, and also check for empty strings explicitly (NULL as represented by PQgetvalue()). That worked correctly before only because parsePGArray() happens to set *nitems = 0 when it fails on an empty string. Also convert a sanity check assertion to an error to be more paranoid, and pgindent a nearby line. Reported-by: Michael Paquier <michael@paquier.xyz>
* In INSERT/UPDATE, use the table's real tuple descriptor as target.Tom Lane2020-11-08
| | | | | | | | | | | | | | | | | | | | | | | This back-patches commit 20d3fe900 into the v12 and v13 branches. At the time I thought that commit was not fixing any observable bug, but Bertrand Drouvot showed otherwise: adding a dropped column to the previously-considered scenario crashes v12 and v13, unless the dropped column happens to be an integer. That is, of course, because the tupdesc we derive from the plan output tlist fails to describe the dropped column accurately, so that we'll do the wrong thing with a tuple in which that column isn't NULL. There is no bug in pre-v12 branches because they already did use the table's real tuple descriptor for any trigger-returned tuple. It seems that this set of bugs can be blamed on the changes that removed es_trig_tuple_slot, though I've not attempted to pin that down precisely. Although there's no code change needed in HEAD, update the test case to include a dropped column there too. Discussion: https://postgr.es/m/db5d97c8-f48a-51e2-7b08-b73d5434d425@amazon.com Discussion: https://postgr.es/m/16644-5da7ef98a7ac4545@postgresql.org
* Fix assertion in collation version lookup.Thomas Munro2020-11-08
| | | | | | | Commit 257836a7 included an assertion that a version lookup routine is not trying to look up "C" or "POSIX", but that case is reachable with the user-facing SQL function pg_collation_actual_version(). Remove the assertion.
* Fix test for error message changePeter Eisentraut2020-11-08
| | | | fix for 6be725e701611660b36642de9ff1d665a1eb24f5
* Improve nbtree README's LP_DEAD section.Peter Geoghegan2020-11-07
| | | | | | | | | | The description of how LP_DEAD bit setting by index scans works following commit 2ed5b87f was rather unclear. Clean that up a bit. Also refer to LP_DEAD bit setting within _bt_check_unique() at the start of the same section. This mechanism may actually be more important than the generic kill_prior_tuple mechanism that the section focuses on, so it at least deserves to be mentioned in passing.
* Message style improvementsAlvaro Herrera2020-11-07
| | | | | | | | | | | | | * Avoid pointlessly highlighting that an index vacuum was executed by a parallel worker; user doesn't care. * Don't give the impression that a non-concurrent reindex of an invalid index on a TOAST table would work, because it wouldn't. * Add a "translator:" comment for a mysterious message. Discussion: https://postgr.es/m/20201107034943.GA16596@alvherre.pgsql Reviewed-by: Michael Paquier <michael@paquier.xyz>
* Fix redundant error messages in client toolsPeter Eisentraut2020-11-07
| | | | | | A few client tools duplicate error messages already provided by libpq. Discussion: https://www.postgresql.org/message-id/flat/3e937641-88a1-e697-612e-99bba4b8e5e4%40enterprisedb.com
* Avoid re-using output variables in new ecpg test case.Tom Lane2020-11-07
| | | | | | | | | The buildfarm thinks this leads to memory stomps, though annoyingly I can't duplicate that here. The existing code in strings.pgc is doing something that doesn't seem to be sanctioned at all really by the documentation, but I'm disinclined to try to make that nicer right now. Let's just declare some more output variables in hopes of working around it.
* Fix ecpg's mishandling of B'...' and X'...' literals.Tom Lane2020-11-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These were broken in multiple ways: * The xbstart and xhstart lexer actions neglected to set "state_before_str_start" before transitioning to the xb/xh states, thus possibly resulting in "internal error: unreachable state" later. * The test for valid string contents at the end of xb state was flat out wrong, as it accounted incorrectly for the "b" prefix that the xbstart action had injected. Meanwhile, the xh state had no such check at all. * The generated literal value failed to include any quote marks. * The grammar did the wrong thing anyway, typically ignoring the literal value and emitting something else, since BCONST and XCONST tokens were handled randomly differently from SCONST tokens. The first of these problems is evidently an oversight in commit 7f380c59f, but the others seem to be very ancient. The lack of complaints shows that ECPG users aren't using these syntaxes much (although I do vaguely remember one previous complaint). As written, this patch is dependent on 7f380c59f, so it can't go back further than v13. Given the shortage of complaints, I'm not excited about adapting the patch to prior branches. Report and patch by Shenhao Wang (test case adjusted by me) Discussion: https://postgr.es/m/d6402f1bacb74ecba22ef715dbba17fd@G08CNEXMBPEKD06.g08.fujitsu.local
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-03 17:12:43 +0000