aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
...
* Make pull_var_clause() handle GroupingFuncs exactly like Aggrefs.Tom Lane2022-05-12
| | | | | | | | | | | | | | | | | This follows in the footsteps of commit 2591ee8ec by removing one more ill-advised shortcut from planning of GroupingFuncs. It's true that we don't intend to execute the argument expression(s) at runtime, but we still have to process any Vars appearing within them, or we risk failure at setrefs.c time (or more fundamentally, in EXPLAIN trying to print such an expression). Vars in upper plan nodes have to have referents in the next plan level, whether we ever execute 'em or not. Per bug #17479 from Michael J. Sullivan. Back-patch to all supported branches. Richard Guo Discussion: https://postgr.es/m/17479-6260deceaf0ad304@postgresql.org
* relnotes: adjust several logical replication items and FK textBruce Momjian2022-05-12
| | | | | | Reported-by: Amit Langote, Amit Kapila, Takamichi Osumi Discussion: https://postgr.es/m/CAA4eK1KdAho_fNkYRe=o=XpxWs_TG4O0V8CJBAvTG8HamWt6OQ@mail.gmail.com
* postgres_fdw: Update comments in make_new_connection().Etsuro Fujita2022-05-12
| | | | | | | | | | | | | | Expand the comment about the parallel_commit option to mention that the default is false. Also, since the comment about alteration of the keep_connections option, which was located above the expanded comment, holds true for the parallel_commit option, rewrite it to reflect this, and move it to after the expanded comment. Follow-up for commit 04e706d42. Discussion: https://postgr.es/m/CAPmGK16Kg2Bf90sqzcZ4YM5cN_G-4h7wFUS01qQpqNB%2B2BG5_w%40mail.gmail.com
* Add some missing PGDLLIMPORT markingsMichael Paquier2022-05-12
| | | | | | | | | | | | | | | | | | Three variables in pqsignal.h (UnBlockSig, BlockSig and StartupBlockSig) were not marked with PGDLLIMPORT, as they are declared in a way that prevents mark_pgdllimport.pl to detect them. These variables are redefined in a style more consistent with the other headers, allowing the script to find and mark them. PGDLLIMPORT was missing for __pg_log_level in logging.h, so add it back. The marking got accidentally removed in 9a374b77, just after its addition in 8ec5694. While on it, add a comment in mark_pgdllimport.pl explaining what are the arguments needed by the script (aka a list of header paths). Reported-by: Andres Freund Discussion: https://postgr.es/m/20220506234924.6mxxotl3xl63db3l@alap3.anarazel.de
* relnotes: mention non-exclusive backup mode was deprecatedBruce Momjian2022-05-11
| | | | | | Reported-by: Ian Lawrence Barwick Discussion: https://postgr.es/m/CAB8KJ=j9VhsFXuN+xv5qzxQV7gj-6TKqqwVLSgz5zU7F8nHCYw@mail.gmail.com
* Use correct datum macros in more tuplesort specialization functions.John Naylor2022-05-12
| | | | | | | | | Also clarify that ApplySignedSortComparator() is not built on 32-bit machines. Folow-up to c90c16591 Reviewed-by: David Rowley Discussion: https://www.postgresql.org/message-id/CAFBsxsFmt4_JUP8XgSJqwaAS9a9s8K8_PvMu%3Dj%3DDfwU%3D8QjNPw%40mail.gmail.com
* relnotes: add author to in-memory sorts itemBruce Momjian2022-05-11
| | | | | | Reported-by: Thomas Munro Discussion: https://postgr.es/m/CA+hUKGKha50-H2ye-9x3PJWU5wBq_MPc2rmVKM1xJ0tL+ntROw@mail.gmail.com
* relnotes: update for non-exclusive backup mode removalBruce Momjian2022-05-11
| | | | | | Reported-by: Ian Lawrence Barwick Discussion: https://postgr.es/m/CAB8KJ=jmLBMAmxjcew12-yntb7m3FH-8A2+Qb7+RybZp1w9GOg@mail.gmail.com
* relnote: improve sorting entriesBruce Momjian2022-05-11
| | | | | | Reported-by: David Rowley Discussion: https://postgr.es/m/CAApHDvrToHFvL-W03vSi6T50uScyhrdUGzTtcuLAjdjtRF8FLA@mail.gmail.com
* Remove non-functional code for unloading loadable modules.Robert Haas2022-05-11
| | | | | | | | | | The code for unloading a library has been commented-out for over 12 years, ever since commit 602a9ef5a7c60151e10293ae3c4bb3fbb0132d03, and we're no closer to supporting it now than we were back then. Nathan Bossart, reviewed by Michael Paquier and by me. Discussion: http://postgr.es/m/Ynsc9bRL1caUSBSE@paquier.xyz
* relnotes: adjustments from Álvaro HerreraBruce Momjian2022-05-11
| | | | | | Reported-by: Álvaro Herrera Discussion: https://postgr.es/m/202205111412.n7xgu3eppins@alvherre.pgsql
* relnotes: update foreign key partition and add sort itemsBruce Momjian2022-05-11
| | | | | | Reported-by: David Rowley, Amit Langote Discussion: https://postgr.es/m/CA+HiwqFcEdbNinfK94aTgBJKmtkYGdtkPnjt3b0fVzKi+WZ+KA@mail.gmail.com
* Fix typos and grammar in code and test commentsMichael Paquier2022-05-11
| | | | | | | | This fixes the grammar of some comments in a couple of tests (SQL and TAP), and in some C files. Author: Justin Pryzby Discussion: https://postgr.es/m/20220511020334.GH19626@telsasoft.com
* Add logging for excessive ProcSignalBarrier waits.Thomas Munro2022-05-11
| | | | | | | | | | | | | To enable diagnosis of systems that are not processing ProcSignalBarrier requests promptly, add a LOG message every 5 seconds if we seem to be wedged. Although you could already see this state as a wait event in pg_stat_activity, the log message also shows the PID of the process that is preventing progress. Also add DEBUG1 logging around the whole wait loop. Reviewed-by: Robert Haas <robertmhaas@gmail.com> Discussion: https://postgr.es/m/CA%2BTgmoYJ03r5359gQutRGP9BtigYCg3_UskcmnVjBf-QO3-0pQ%40mail.gmail.com
* Fix the logical replication timeout during large transactions.Amit Kapila2022-05-11
| | | | | | | | | | | | | | | | | | | The problem is that we don't send keep-alive messages for a long time while processing large transactions during logical replication where we don't send any data of such transactions. This can happen when the table modified in the transaction is not published or because all the changes got filtered. We do try to send the keep_alive if necessary at the end of the transaction (via WalSndWriteData()) but by that time the subscriber-side can timeout and exit. To fix this we try to send the keepalive message if required after processing certain threshold of changes. Reported-by: Fabrice Chapuis Author: Wang wei and Amit Kapila Reviewed By: Masahiko Sawada, Euler Taveira, Hou Zhijie, Hayato Kuroda Backpatch-through: 10 Discussion: https://postgr.es/m/CAA5-nLARN7-3SLU_QUxfy510pmrYK6JJb=bk3hcgemAM_pAv+w@mail.gmail.com
* Silence extra logging when using "postgres -C" on runtime-computed GUCsMichael Paquier2022-05-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Presently, the server may emit a variety of log messages when inspecting a runtime-computed GUC, mostly in the shape of one LOG message with the default configuration, related to the startup sequence launched as such GUCs require a load of the control file and of external shared libraries. For example, the server will always emit a "database system is shut down" LOG (unless the user has set log_min_messages higher than LOG), which is an annoying behavior as "postgres -C" is expected to only emit in its output the parameter value we are looking for. The parameter value is sent to stdout, while the logs are sent to stderr so we could recommend to use a redirection, but there was not much love for this workaround either. To avoid such extra log messages, per discussion, this change sets log_min_messages to FATAL internally when -C is used on a runtime-computed GUC (even if set to PANIC in postgresql.conf). At FATAL, the user will still receive messages explaining why a GUC value cannot be inspected, and will know if the command is attempted on a server already running, something not supported yet for a runtime-computed GUC. Reported-by: Magnus Hagander, Bruce Momjian Author: Nathan Bossart, Michael Paquier Discussion: https://postgr.es/m/Yni6ZHkGotUU+RSf@paquier.xyz
* Add missing source files to nls.mkPeter Eisentraut2022-05-11
|
* relnotes: more adjustmentsBruce Momjian2022-05-10
| | | | | | Reported-by: Justin Pryzby Discussion: https://postgr.es/m/20220511013117.GG19626@telsasoft.com
* relnotes: logical replication permissions checked by subscrib.Bruce Momjian2022-05-10
| | | | | | Reported-by: Mark Dilger Discussion: https://postgr.es/m/F3D44160-F41A-4F2E-AED5-5C15B6903AC4@enterprisedb.com
* relnotes: adjustmentsBruce Momjian2022-05-10
| | | | | | | | Remove SSL item backpatched (Jonathan S. Katz), adjust logical replication item (Mark Dilger), adjust --compress wording (Justin Pryzby). Discussion: https://postgr.es/m/20220511012854.GF19626@telsasoft.com
* Improve setup of environment values for commands in MSVC's vcregress.plMichael Paquier2022-05-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current setup assumes that commands for lz4, zstd and gzip always exist by default if not enforced by a user's environment. However, vcpkg, as one example, installs libraries but no binaries, so this default setup to assume that a command should always be present would cause failures. This commit improves the detection of such external commands as follows: * If a ENV value is available, trust the environment/user and use it. * If a ENV value is not available, check its execution by looking in the current PATH, by launching a simple "$command --version" (that should be portable enough). ** On execution failure, ignore ENV{command}. ** On execution success, set ENV{command} = "$command". Note that this new rule applies to gzip, lz4 and zstd but not tar that we assume will always exist. Those commands are set up in the environment only when using bincheck and taptest. The CI includes all those commands and I have checked that their setup is correct there. I have also tested this change in a MSVC environment where we have none of those commands. While on it, remove the references to lz4 from the documentation and vcregress.pl in ~v13. --with-lz4 has been added in v14~ so there is no point to have this information in these older branches. Reported-by: Andrew Dunstan Reviewed-by: Andrew Dunstan Discussion: https://postgr.es/m/14402151-376b-a57a-6d0c-10ad12608e12@dunslane.net Backpatch-through: 10
* Fix some incorrect preprocessor tests in tuplesort specializationsDavid Rowley2022-05-11
| | | | | | | | | | | | | | | | | | | | | | | | | 697492434 added 3 new quicksort specialization functions for common datatypes. That commit was not very consistent in how it would determine if we're compiling for 32-bit or 64-bit machines. It would sometimes use USE_FLOAT8_BYVAL and at other times check if SIZEOF_DATUM == 8. This could cause theoretical problems due to the way USE_FLOAT8_BYVAL is now defined based on SIZEOF_VOID_P >= 8. If pointers for some reason were ever larger than 8-bytes then we'd end up doing 32-bit comparisons mistakenly. Let's just always check SIZEOF_DATUM >= 8. It also seems that ssup_datum_signed_cmp is just never used on 32-bit builds, so let's just ifdef that out to make sure we never accidentally use that comparison function on such machines. This also allows us to ifdef out 1 of the 3 new specialization quicksort functions in 32-bit builds which seems to shrink down the binary by over 4KB on my machine. In passing, also add the missing DatumGetInt32() / DatumGetInt64() macros in the comparison functions. Discussion: https://postgr.es/m/CAApHDvqcQExRhtRa9hJrJB_5egs3SUfOcutP3m+3HO8A+fZTPA@mail.gmail.com Reviewed-by: John Naylor
* configure: don't probe for libldap_r if libldap is 2.5 or newer.Tom Lane2022-05-10
| | | | | | | | | | | | | | | | | | | | In OpenLDAP 2.5 and later, libldap itself is always thread-safe and there's never a libldap_r. Our existing coding dealt with that by assuming it wouldn't find libldap_r if libldap is thread-safe. But that rule fails to cope if there are multiple OpenLDAP versions visible, as is likely to be the case on macOS in particular. We'd end up using shiny new libldap in the backend and a hoary libldap_r in libpq. Instead, once we've found libldap, check if it's >= 2.5 (by probing for a function introduced then) and don't bother looking for libldap_r if so. While one can imagine library setups that this'd still give the wrong answer for, they seem unlikely to occur in practice. Per report from Peter Eisentraut. Back-patch to all supported branches. Discussion: https://postgr.es/m/fedacd7c-2a38-25c9-e7ff-dea549d0e979@enterprisedb.com
* relnotes: adjust sections for various itemsBruce Momjian2022-05-10
| | | | | | | | Also improve postgres_fdw.application_name Reported-by: Justin Pryzby, Tatsuo Ishii Diagnosed-by: 20220510210235.GD19626@telsasoft.com
* relnote: add ARM64 spinlock itemBruce Momjian2022-05-10
| | | | | | Reported-by: Jonathan Katz Discussion: per private email
* relnotes: remove sequence replication and update 'postgres -C'Bruce Momjian2022-05-10
| | | | | | Reported-by: Nathan Bossart, Jonathan Katz Discussion: https://postgr.es/m/20220510194456.GA3716556@nathanxps13
* relnote: extensive updatesBruce Momjian2022-05-10
| | | | | | Reported-by: Erik Rijkers, Justin Pryzby Discussion: https://postgr.es/m/20220510180935.GB19626@telsasoft.com
* Formatting and punctuation improvements in sample configuration filesPeter Eisentraut2022-05-10
|
* Remove some tabs in SQL code in C string literalsPeter Eisentraut2022-05-10
| | | | | This is not handled uniformly throughout the code, but at least nearby code can be consistent.
* doc: Update SQL keywords for SQL:2016 technical corrigendaPeter Eisentraut2022-05-10
| | | | | | | | | | | | | | | Several keywords were missing or misclassified in the original SQL:2016 standard. This has been corrected in later technical corrigenda. This change updates the PostgreSQL documentation accordingly. This also fixes a mistake in 606948b058d: The keywords JSON_SCALAR and JSON_SERIALIZE added there are not from SQL:2016 but from future SQL:202x, so they don't belong in that list yet. (606948b058d also added JSON to the reserved list, which is what the corrigendum also does, but failed to remove it from the nonreserved list.)
* relnotes: "training" -> "trailing"Bruce Momjian2022-05-10
| | | | | | Reported-by: Geoff Winkless Discussion: https://postgr.es/m/CAEzk6fdF_J4jqicLz=FZ6R1u2EjpEtmzD55tFjVbxw-O-kR1=w@mail.gmail.com
* doc: first draft of PG 15 release notesBruce Momjian2022-05-10
|
* Fix several issues with the TAP tests of pg_upgradeMichael Paquier2022-05-10
| | | | | | | | | | | | | | | | | | | | | | | This commit addresses the following issues in the TAP tests of pg_upgrade, introduced in 322becb: - Remove --port and --host for commands that already rely on a node's environment PGHOST and PGPORT. - Switch from run_log() to command_ok(), as all the commands executed in the tests should succeed. - Change EXTRA_REGRESS_OPTS to make it count as a shell fragment (fixing s/OPT/OPTS on a way), to be compatible with the various Makefiles using it as well as 027_stream_regress.pl in the recovery tests. The command built for the execution the pg_regress command is reformatted, while on it, to map with the recovery test doing the same thing (we should refactor and consolidate that in the future, perhaps). - Re-add the test for database names stressing the behavior of backslashes with double quotes, mostly here for Windows. Tests doable with the upgrade across different major versions still work the same way. Reported-by: Noah Misch Discussion: https://postgr.es/m/20220502042718.GB1565149@rfd.leadboat.com
* Fix core dump in transformValuesClause when there are no columns.Tom Lane2022-05-09
| | | | | | | | | | | | The parser code that transformed VALUES from row-oriented to column-oriented lists failed if there were zero columns. You can't write that straightforwardly (though probably you should be able to), but the case can be reached by expanding a "tab.*" reference to a zero-column table. Per bug #17477 from Wang Ke. Back-patch to all supported branches. Discussion: https://postgr.es/m/17477-0af3c6ac6b0a6ae0@postgresql.org
* Revert "Disallow infinite endpoints in generate_series() for timestamps."Tom Lane2022-05-09
| | | | | | | | | | | | | | | | | | | This reverts commit eafdf9de06e9b60168f5e47cedcfceecdc6d4b5f and its back-branch counterparts. Corey Huinker pointed out that we'd discussed this exact change back in 2016 and rejected it, on the grounds that there's at least one usage pattern with LIMIT where an infinite endpoint can usefully be used. Perhaps that argument needs to be re-litigated, but there's no time left before our back-branch releases. To keep our options open, restore the status quo ante; if we do end up deciding to change things, waiting one more quarter won't hurt anything. Rather than just doing a straight revert, I added a new test case demonstrating the usage with LIMIT. That'll at least remind us of the issue if we forget again. Discussion: https://postgr.es/m/3603504.1652068977@sss.pgh.pa.us Discussion: https://postgr.es/m/CADkLM=dzw0Pvdqp5yWKxMd+VmNkAMhG=4ku7GnCZxebWnzmz3Q@mail.gmail.com
* In REFRESH MATERIALIZED VIEW, set user ID before running user code.Noah Misch2022-05-09
| | | | | | | | | | It intended to, but did not, achieve this. Adopt the new standard of setting user ID just after locking the relation. Back-patch to v10 (all supported versions). Reviewed by Simon Riggs. Reported by Alvaro Herrera. Security: CVE-2022-1552
* Make relation-enumerating operations be security-restricted operations.Noah Misch2022-05-09
| | | | | | | | | | | | | | | | | | When a feature enumerates relations and runs functions associated with all found relations, the feature's user shall not need to trust every user having permission to create objects. BRIN-specific functionality in autovacuum neglected to account for this, as did pg_amcheck and CLUSTER. 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. CREATE INDEX (not a relation-enumerating operation) and REINDEX protected themselves too late. This change extends to the non-enumerating amcheck interface. Back-patch to v10 (all supported versions). Sergey Shinderuk, reviewed (in earlier versions) by Alexander Lakhin. Reported by Alexander Lakhin. Security: CVE-2022-1552
* Add missing source files to nls.mkPeter Eisentraut2022-05-09
|
* Fix control file update done in restartpoints still running after promotionMichael Paquier2022-05-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a cluster is promoted (aka the control file shows a state different than DB_IN_ARCHIVE_RECOVERY) while CreateRestartPoint() is still processing, this function could miss an update of the control file for "checkPoint" and "checkPointCopy" but still do the recycling and/or removal of the past WAL segments, assuming that the to-be-updated LSN values should be used as reference points for the cleanup. This causes a follow-up restart attempting crash recovery to fail with a PANIC on a missing checkpoint record if the end-of-recovery checkpoint triggered by the promotion did not complete while the cluster abruptly stopped or crashed before the completion of this checkpoint. The PANIC would be caused by the redo LSN referred in the control file as located in a segment already gone, recycled by the previous restartpoint with "checkPoint" out-of-sync in the control file. This commit fixes the update of the control file during restartpoints so as "checkPoint" and "checkPointCopy" are updated even if the cluster has been promoted while a restartpoint is running, to be on par with the set of WAL segments actually recycled in the end of CreateRestartPoint(). This problem exists in all the stable branches. However, commit 7ff23c6, by removing the last call of CreateCheckPoint() from the startup process, has made this bug much easier to reason about as concurrent checkpoints are not possible anymore. No backpatch is done yet, mostly out of caution from me as a point release is close by, but we need to think harder about the case of concurrent checkpoints at promotion if the bgwriter is not considered as running by the startup process in ~v14, so this change is done only on HEAD for the moment. Reported-by: Fujii Masao, Rui Zhao Author: Kyotaro Horiguchi Reviewed-by: Nathan Bossart, Michael Paquier Discussion: https://postgr.es/m/20220316.102444.2193181487576617583.horikyota.ntt@gmail.com
* Fix race in 032_relfilenode_reuse.pl.Thomas Munro2022-05-08
| | | | | | | | | Add wait_for_catchup() call to the test added by commit e2f65f42. Per slow build farm animal grison. Also fix a comment. Discussion: https://postgr.es/m/CA%2BhUKGLJ2Vy8hVQmnYotmTaEKZK0%3D-GcXgNAgcHzArZvtS4L_g%40mail.gmail.com
* Under has_wal_read_bug, skip contrib/bloom/t/001_wal.pl.Noah Misch2022-05-07
| | | | | | | Per buildfarm members snapper and kittiwake. Back-patch to v10 (all supported versions). Discussion: https://postgr.es/m/20220116210241.GC756210@rfd.leadboat.com
* Fix old-fd issues using global barriers everywhere.Thomas Munro2022-05-07
| | | | | | | | | | | | | | | | | | | | | Commits 4eb21763 and b74e94dc introduced a way to force every backend to close all relation files, to fix an ancient Windows-only bug. This commit extends that behavior to all operating systems and adds a couple of extra barrier points, to fix a totally different class of bug: the reuse of relfilenodes in scenarios that have no other kind of cache invalidation to prevent file descriptor mix-ups. In all releases, data corruption could occur when you moved a database to another tablespace and then back again. Despite that, no back-patch for now as the infrastructure required is too new and invasive. In master only, since commit aa010514, it could also happen when using CREATE DATABASE with a user-supplied OID or via pg_upgrade. Author: Andres Freund <andres@anarazel.de> Reviewed-by: Robert Haas <robertmhaas@gmail.com> Reviewed-by: Thomas Munro <thomas.munro@gmail.com> Discussion: https://postgr.es/m/20220209220004.kb3dgtn2x2k2gtdm%40alap3.anarazel.de
* Rethink PROCSIGNAL_BARRIER_SMGRRELEASE.Thomas Munro2022-05-07
| | | | | | | | | | | | | | | | With sufficiently bad luck, it was possible for IssuePendingWritebacks() to reopen a file after we'd processed PROCSIGNAL_BARRIER_SMGRRELEASE and before the file was unlinked by some other backend. That left a small hole in commit 4eb21763's plan to fix all spurious errors from DROP TABLESPACE and similar on Windows. Fix by closing md.c's segments, instead of just closing fd.c's descriptors, and then teaching smgrwriteback() not to open files that aren't already open. Reported-by: Andres Freund <andres@anarazel.de> Reviewed-by: Robert Haas <robertmhaas@gmail.com> Discussion: https://postgr.es/m/20220209220004.kb3dgtn2x2k2gtdm%40alap3.anarazel.de
* Fix misleading comments about background worker registration.Robert Haas2022-05-06
| | | | | | | | | | | | | | | | Since 6bc8ef0b7f1f1df3998745a66e1790e27424aa0c, the maximum number of backends can't change as background workers are registered, but these comments still reflect the way things worked prior to that. Also, per recent discussion, some modules call SetConfigOption() from _PG_init(). It's not entirely clear to me whether we want to regard that as a fully supported operation, but since we know it's a thing that happens, it at least deserves a mention in the comments, so add that. Nathan Bossart, reviewed by Anton A. Melnikov Discussion: http://postgr.es/m/20220419154658.GA2487941@nathanxps13
* pgcrypto: remove questionmark from error messageDaniel Gustafsson2022-05-06
| | | | | | | | The PXE_CIPHER_INIT error is used to report initialization errors, so appending a questionmark to the error isn't entirely accurate (using a space before the questionmark doubly so). Discussion: https://postgr.es/m/C89D932C-501E-4473-9750-638CFCD9095E@yesql.se
* pgcrypto: report init errors as PXE_CIPHER_INITDaniel Gustafsson2022-05-06
| | | | | | | | Report OpenSSL errors during initialization as PXE_CIPHER_INIT since that's just what they were, and not generic unknown errors. This also removes the last users of the generic error, and thus it can be removed. Discussion: http://postgr.es/m/C89D932C-501E-4473-9750-638CFCD9095E@yesql.se
* Clear the OpenSSL error queue before cryptohash operationsDaniel Gustafsson2022-05-06
| | | | | | | | | | | | | | | | Setting up an EVP context for ciphers banned under FIPS generate two OpenSSL errors in the queue, and as we only consume one from the queue the other is at the head for the next invocation: postgres=# select md5('foo'); ERROR: could not compute MD5 hash: unsupported postgres=# select md5('foo'); ERROR: could not compute MD5 hash: initialization error Clearing the error queue when creating the context ensures that we don't pull in an error from an earlier operation. Discussion: https://postgr.es/m/C89D932C-501E-4473-9750-638CFCD9095E@yesql.se
* Fix typo in origin.cMichael Paquier2022-05-06
| | | | | | | Introduced in 5aa2350. Author: Peter Smith Discussion: https://postgr.es/m/CAHut+PsuWz6_7aCmivNU5FahgQxDUTQtc3+__XnWkBzQcfn43w@mail.gmail.com
* Update SQL featuresPeter Eisentraut2022-05-06
| | | | | Update a few items that have become supported or mostly supported but weren't updated at the time.
* Fix some whitespace in documentation markupPeter Eisentraut2022-05-06
|
generated by cgit v1.2.3 (git 2.25.1) at 2025-07-30 19:29:39 +0000