PostgreSQL Database Server

Nordic PGDay 2022 will be held in Helsinki, Finland, on March 22nd 2022, a the Hilton Helsinki Strand. The schedule has now been published. All sessions will be held in English. Registration for the event remains open. Early bird registration using ... [More] the code EARLYBIRD is available until February 22nd as long as supply lasts. The conference team would like to thank all our sponsors for making this event possible! Please see updated information about our COVID-19 policies on our webste, See you in Helsinki in March! [Less]

The next edition of the popular PostgreSQL conference pgDay Paris, a PostgreSQL.Org Recognized Community Conference, will be held on March 24, 2022 in the French capital. All of the talks will be in English. Registration is open, and the EARLYBIRD ... [More] discount is going fast so make sure you grab that while you can! We received over 100 talk proposals for only 8 slots! This allowed us to prepare an exciting schedule for you, with speakers from around the world, including the United States, Sweden, Poland, Germany, Belgium, and of course France; speaking on a wide range of topics, sure to please everyone. Finally, none of this would be possible without our sponsors! See them (or even join them!) here. For more information and videos from previous years, see the website. See you all on March 24th! -- The pgDay Paris Team [Less]

Paris, France, 14 january 2022 A new maintainance version for temBoard 7 is just released. This 7.9 version includes PostgreSQL 14 support, bugfixes and performance improvements. temBoard is a monitoring and administration tool for PostgreSQL ... [More] instances fleet. Its non-intrusive design eases deployment without weakening your PostgreSQL instance. temBoard alerts you, allows you to handle locks, bloat, configuration and more remotely. PostgreSQL 14 You can monitor and administer PostgreSQL 14 instances with temBoard agent 7.9. temBoard documentation now includes a page about administered instance upgrade. Likewise, you can deploy temBoard 7.9 with PostgreSQL 14 to store monitoring data. A new page in the documentation explain the steps to acheive this upgrade. Performances temBoard 7.9 improves monitoring supervision on fleet of hundreds of instances. This update requires a schema upgrade to do this. Follow update steps described in upgrade documentation. And more… temBoard UI and agent log messages has been improved to better diagnostic monitoring and performance issues. Project documentation has been restructured for better readability and consistency. Note that support for Debian Jessie and Debian Wheezy is now ended. Read further in the following pages: Changelog of 7.9. temBoard on GitHub. Documentation. Availability Follow installation documentation to get temBoard from sources, RPM or deb packages. temBoard is a free software maintained by Dalibo Labs. [Less]

The pgAdmin Development Team is pleased to announce pgAdmin 4 version 6.4. This release of pgAdmin 4 includes 13 bug fixes and new features. For more details please see the release notes. pgAdmin is the leading Open Source graphical management tool ... [More] for PostgreSQL. For more information, please see the website. Notable changes in this release include: Features: Added support to import/export server groups and servers from GUI. This feature allows the users to export server definitions (and their groups) to a JSON file and re-imported them to the same or a different system to enable easy pre-configuration of pgAdmin. Previously this could be done using the 'setup.py' command-line script but after the implementation of this new feature, it can be done using the Import/Export Servers Wizard. Bugs/Housekeeping: Port Maintenance, and Restore dialog in React. Fixed an issue where Explain Analyze shows negative exclusive time. Fixed an issue where Columns with default value not showing when adding a new row. Fixed an issue where the Owner is not displayed in the reverse engineering SQL for Procedures. Fixed an issue where an operation error message popped up showing the database object's name incorrectly. Fixed an issue where SubPlans may overlap other nodes & make them inaccessible in Graphical EXPLAIN View. Fixed a schema diff issue where the generated script adds unwanted line endings for Functions/Procedures/Trigger Functions. Builds for Windows and macOS are available now, along with a Python Wheel, Docker Container, RPM, DEB Package, and source code tarball from the tarball area. [Less]

New version of OraDump-to-PostgreSQL has been released with the following improvements: improved migration of spatial data (SDO_GEOMETRY) SSL connection to PostgreSQL server is supported verified support for Azure PostgreSQL More details are available at OraDump-to-PostgreSQL homepage

The pgagroal community is happy to announce version 1.4.0. New features Initial support for TLS communication between pgagroal and PostgreSQL pgagroal pgagroal is a high-performance protocol-native connection pool for PostgreSQL. Features High ... [More] performance Connection pool Limit connections for users and databases Prefill support Remove idle connections Perform connection validation Enable / disable database access Graceful / fast shutdown Prometheus support Grafana 8 dashboard Remote management Authentication query support Failover support Transport Layer Security (TLS) v1.2+ support Daemon mode User vault Learn more on our web site or GitHub. Follow on Twitter. pgagroal is released under the 3-clause BSD license, and is sponsored by Red Hat. [Less]

Hello! pgsodium 2.0.0 is a postgres extension that uses the libsodium library to provide high-performance, modern cryptography support for PostgreSQL 10+. 2.0.0 includes a ton of new feature and a few bug-fixes: Support for XChaCha20-SIV ... [More] deterministic nonce-free encryption Support for SignCryption Sign & Encrypt identity verification Key id support for HMACSHA 512/256, generichash, and shorthash Support for low level XChaCha20 streaming More tests, docs, and small bug fixes in argument parsing In-memory key now protected with sodium_malloc Check it out at: https://github.com/michelp/pgsodium Please feel free to submit any issues you may have and as usual pull requests are greatly appreciated! [Less]

PostgreSQL Weekly News - January 2, 2022 PostgreSQL Product News Pgpool-II 4.2.7, 4.1.10, 4.0.17, and 3.7.22 a connection pooler and statement replication system for PostgreSQL, re le as ed. parquet_s3_fdw 0.2.1, a foreign data wrapper for parquet ... [More] files on S3, released. Database Lab 3.0, a tool for fast cloning of large PostgreSQL databases to build non-production environments, released. sqlite_fdw 2.1.1 released. DynamoDB FDW 1.1.0 released. pg_query_rewrite 0.0.3, a rewriter for certain types of PostgreSQL statements, released. InfluxDB fdw 1.1.1 released https://github.com/pgspider/influxdb_fdw pgspider v2.0, a cluster engine for distributed data based on PostgreSQL foreign data wrappers, released. pg_builder 2.0.0 a PHP query builder for PostgreSQL, released. JDBC FDW 0.1.0 released griddb_fdw 2.1.1 released. https://github.com/pgspider/griddb_fdw PostgreSQL Jobs for January https://archives.postgresql.org/pgsql-jobs/2022-01/ PostgreSQL Local Nordic PGDay 2022 will be held in Helsinki, Finland at the Hilton Helsinki Strand Hotel on March 22, 2022. here pgDay Paris 2022 will be held in Paris, France on March 24, 2022. FOSDEM PGDay 2022 will be held on line, on Feb 5-6, 2022. https://fosdem.org/2022/ Citus Con, a virtual global developer event, is happening April 12-13, 2022. The CFP is now open. PostgreSQL in the News Planet PostgreSQL: https://planet.postgresql.org/ PostgreSQL Weekly News is brought to you this week by David Fetter Submit news and announcements by Sunday at 3:00pm PST8PDT to [email protected]. Applied Patches Peter Eisentraut pushed: doc: More documentation on regular expressions and SQL standard. Reviewed-by: Gilles Darold [email protected] Discussion: https://www.postgresql.org/message-id/[email protected] https://git.postgresql.org/pg/commitdiff/222b697ec077047024a96392a2f5cb9b1803ccf7 pg_dump: Refactor getIndexes(). Rearrange the version-dependent pieces in the new more modular style. Discussion: https://www.postgresql.org/message-id/flat/67a28a3f-7b79-a5a9-fcc7-947b170e66f0%40enterprisedb.com https://git.postgresql.org/pg/commitdiff/e2c52beecdea152ca680a22ef35c6a7da55aa30f Fix typo in code comment. Reported-by: Kevin Zheng [email protected] Discussion: https://www.postgresql.org/message-id/flat/17341-d913ddb626c5c08c%40postgresql.org https://git.postgresql.org/pg/commitdiff/962951be3ce319052df014e0d23b6e7626df587f Fix incorrect format placeholders. https://git.postgresql.org/pg/commitdiff/dfaa346c7c00ff8a3fd8ea436a7d5be7527e67cb Remove unused include. "fmgr.h" was used for load_external_function(), added by a05dc4d7fd57d4ae084c1f0801973e5c1a1aa26e, removed by f9143d102ffd0947ca904c62b1d3d6fd587e0c80. https://git.postgresql.org/pg/commitdiff/2f4fd1a73ba59247d4413f33d6178bbcbcfab60f Remove unused include. "utils/builtins.h" was used for pg_strtouint64(), added by cff440d368690f94fbda1a475277e90ea2263843, removed by 3c6f8c011f85df7b35c32f4ccaac5c86c9064a4a. https://git.postgresql.org/pg/commitdiff/4965f75484aea9d273b11ad4957f57d8dc1ed4b0 Fix incorrect format placeholders. https://git.postgresql.org/pg/commitdiff/113fa3945f8969346d6a87b9a56d54afa3d34687 John Naylor pushed: Add fast path for validating UTF-8 text. Our previous validator used a traditional algorithm that performed comparison and branching one byte at a time. It's useful in that we always know exactly how many bytes we have validated, but that precision comes at a cost. Input validation can show up prominently in profiles of COPY FROM, and future improvements to COPY FROM such as parallelism or faster line parsing will put more pressure on input validation. Hence, add fast paths for both ASCII and multibyte UTF-8: Use bitwise operations to check 16 bytes at a time for ASCII. If that fails, use a "shift-based" DFA on those bytes to handle the general case, including multibyte. These paths are relatively free of branches and thus robust against all kinds of byte patterns. With these algorithms, UTF-8 validation is several times faster, depending on platform and the input byte distribution. The previous coding in pg_utf8_verifystr() is retained for short strings and for when the fast path returns an error. Review, performance testing, and additional hacking by: Heikki Linakangas, Vladimir Sitnikov, Amit Khandekar, Thomas Munro, and Greg Stark Discussion: https://www.postgresql.org/message-id/CAFBsxsEV_SzH%2BOLyCiyon%3DiwggSyMh_eF6A3LU2tiWf3Cy2ZQg%40mail.gmail.com https://git.postgresql.org/pg/commitdiff/911588a3f816d875261d8f7d89e2517978831cd5 Tom Lane pushed: Add a \getenv command to psql. \getenv fetches the value of an environment variable into a psql variable. This is the inverse of the \setenv command that was added over ten years ago. We'd not seen a compelling use-case for \getenv at the time, but upcoming regression test refactoring provides a sufficient reason to add it now. Discussion: https://postgr.es/m/[email protected] https://git.postgresql.org/pg/commitdiff/33d3eeadb21d2268104840cfef6bc2226ddfc680 Remove dynamic translation of regression test scripts, step 1. pg_regress has long had provisions for dynamically substituting path names into regression test scripts and result files, but use of that feature has always been a serious pain in the neck, mainly because updating the result files requires tedious manual editing. Let's get rid of that in favor of passing down the paths in environment variables. In addition to being easier to maintain, this way is capable of dealing with path names that require escaping at runtime, for example paths containing single-quote marks. (There are other stumbling blocks in the way of actually building in a path that looks like that, but removing this one seems like a good thing to do.) The key coding rule that makes that possible is to concatenate pieces of a dynamically-variable string using psql's \set command, and then use the :'variable' notation to quote and escape the string for the next level of interpretation. In hopes of making this change more transparent to "git blame", I've split it into two steps. This commit adds the necessary pg_regress.c support and changes all the *.source files in-place so that they no longer require any dynamic translation. The next commit will just "git mv" them into the regular sql/ and expected/ directories. Discussion: https://postgr.es/m/[email protected] https://git.postgresql.org/pg/commitdiff/d1029bb5a26cb84b116b0dee4dde312291359f2a Remove dynamic translation of regression test scripts, step 2. "git mv" all the input/.source and output/.source files into the corresponding sql/ and expected/ directories. Then remove the pg_regress and Makefile infrastructure associated with dynamic translation. Discussion: https://postgr.es/m/[email protected] https://git.postgresql.org/pg/commitdiff/dc9c3b0ff21465fa89d71eecf5e6cc956d647eca Merge dblink's paths test script into its main test. There's no longer any reason to fire up a separate psql run to create these functions. (Some refactoring in the main regression tests is also called for, but that will take more thought.) Discussion: https://postgr.es/m/[email protected] https://git.postgresql.org/pg/commitdiff/0e6e7f0806b2080cb31f33ff992ec2e4e35fa6f1 Add missing EmitWarningsOnPlaceholders() calls. Extensions that define any custom GUCs should call EmitWarningsOnPlaceholders after doing so, to help catch misspellings. Many of our contrib modules hadn't gotten the memo on that, though. Also add such calls to src/test/modules extensions that have GUCs. While these aren't really user-facing, they should illustrate good practice not faulty practice. Shinya Kato Discussion: https://postgr.es/m/[email protected] https://git.postgresql.org/pg/commitdiff/1fada5d81e6769ded832a4ca62ee9371bac3fb9f Add help & tab-complete support for psql's \getenv. I forgot about these details in 33d3eeadb :-(. Noted by Christoph Berg. Discussion: https://postgr.es/m/YcI8i/[email protected] https://git.postgresql.org/pg/commitdiff/0f2abd05441f524a67bc58ef5f0cc32054f7fb66 Rethink handling of settings with a prefix reserved by an extension. Commit 75d22069e made SET print a warning if you tried to set an unrecognized parameter within namespace previously reserved by an extension. It seems better for that to be an outright error though, for the same reason that we don't let you set unrecognized unqualified parameter names. In any case, the preceding implementation was inefficient and erroneous. Perform the check in a more appropriate spot, and be more careful about prefix-match cases. Discussion: https://postgr.es/m/[email protected] https://git.postgresql.org/pg/commitdiff/2ed8a8cc5b634d33ea07d681c6b02213da07f792 Rename EmitWarningsOnPlaceholders() to MarkGUCPrefixReserved(). This seems like a clearer name for what it does now. Provide a compatibility macro so that extensions don't have to convert to the new name right away. Discussion: https://postgr.es/m/[email protected] https://git.postgresql.org/pg/commitdiff/5609cc01c69b80f8788771dc6f5696a459469119 Revert changes about warnings/errors for placeholders. Revert commits 5609cc01c, 2ed8a8cc5, and 75d22069e until we have a less broken idea of how this should work in parallel workers. Per buildfarm. Discussion: https://postgr.es/m/[email protected] https://git.postgresql.org/pg/commitdiff/cab5b9ab2c066ba904f13de2681872dcda31e207 Fix issues in pgarch's new directory-scanning logic. The arch_filenames[] array elements were one byte too small, so that a maximum-length filename would get corrupted if another entry were made after it. (Noted by Thomas Munro, fix by Nathan Bossart.) Move these arrays into a palloc'd struct, so that we aren't wasting a few kilobytes of static data in each non-archiver process. Add a binaryheap_reset() call to make it plain that we start the directory scan with an empty heap. I don't think there's any live bug of that sort, but it seems fragile, and this is very cheap insurance. Cleanup for commit beb4e9ba1, so no back-patch needed. Discussion: https://postgr.es/m/CA+hUKGLHAjHuKuwtzsW7uMJF4BVPcQRL-UMZG_HM-g0y7yLkUg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/1fb17b1903414676bd371068739549cd2966fe87 Minor cleanup/optimization in pg_dump. In the wake of commits 05649b88c and 5209c0ba0, findComments() and findSecLabels() no longer use their "Archive *fout" arguments, so get rid of those. While doing that, I noticed that there's no very good reason why dumpCompositeTypeColComments() should be doing its own query to fetch the column names of the composite type, when the calling function has just fetched the same data. Tweak it to use that query result. This probably doesn't save a lot for most people, because since 5209c0ba0 we won't get into this code at all unless the composite type has at least one comment. Nonetheless, it's a wasted query. https://git.postgresql.org/pg/commitdiff/c7cf73eb7b9e7911748ebe117a7219f21e504121 pg_dump: make dumpPublication et al. less unlike sibling functions. dumpPublication, dumpPublicationNamespace, dumpPublicationTable, and dumpSubscription failed to check dataOnly. This is just a latent bug, because pg_backup_archiver.c would filter out the ArchiveEntry later; but they're wasting cycles in data-only dumps, and the omission might become a live bug someday. In any case, it's not good to have some dumpFoo functions do this and some not. On the same reasoning, make dumpPublicationNamespace follow the same pattern as every other dumpFoo function for checking the DUMP_COMPONENT_DEFINITION flag. (Since 5209c0ba0, we wouldn't even get here if that flag isn't set, so checking it is just pro forma right now. But it might not be so forever.) Since this is just cosmetic and/or future-proofing, no need for back-patch. https://git.postgresql.org/pg/commitdiff/5e65df64d631257ce60016bec0aca43f042b1d33 pg_dump: minor performance improvements from eliminating sub-SELECTs. Get rid of the "username_subquery" mechanism in favor of doing local lookups of role names from role OIDs. The PG backend isn't terribly smart about scalar SubLinks in SELECT output lists, so this offers a small performance improvement, at least in installations with more than a couple of users. In any case the old method didn't make for particularly readable SQL code. While at it, I removed the various custom warning messages about failing to find an object's owner, in favor of just fatal'ing in the local lookup function. AFAIK there is no reason any longer to treat that as anything but a catalog-corruption case, and certainly no reason to make translators deal with a dozen different messages where one would do. (If it turns out that fatal() is indeed a bad idea, we can back off to issuing pg_log_warning() and returning an empty string, resulting in the same behavior as before, except more consistent.) Also drop an entirely unnecessary sub-SELECT to check on the pg_depend status of a sequence relation: we already have a LEFT JOIN to fetch the row of interest in the FROM clause. Discussion: https://postgr.es/m/[email protected] https://git.postgresql.org/pg/commitdiff/d5e8930f50e31d836d84b353b9dadedd5007bb70 pg_dump: avoid unsafe function calls in getPolicies(). getPolicies() had the same disease I fixed in other places in commit e3fcbbd62, i.e., it was calling pg_get_expr() for expressions on tables that we don't necessarily have lock on. To fix, restrict the query to only collect interesting rows, rather than doing the filtering on the client side. Like the previous patch, apply to HEAD only for now. Discussion: https://postgr.es/m/[email protected] Discussion: https://postgr.es/m/[email protected] https://git.postgresql.org/pg/commitdiff/3e6e86abca0138abd7265306beb6346dc2d9e221 Fix index-only scan plans when not all index columns can be returned. If an index has both returnable and non-returnable columns, and one of the non-returnable columns is an expression using a Var that is in a returnable column, then a query returning that expression could result in an index-only scan plan that attempts to read the non-returnable column, instead of recomputing the expression from the returnable column as intended. To fix, redefine the "indextlist" list of an IndexOnlyScan plan node as containing null Consts in place of any non-returnable columns. This solves the problem by preventing setrefs.c from falsely matching to such entries. The executor is happy since it only cares about the exposed types of the entries, and ruleutils.c doesn't care because a correct plan won't reference those entries. I considered some other ways to prevent setrefs.c from doing the wrong thing, but this way seems good since (a) it allows a very localized fix, (b) it makes the indextlist structure more compact in many cases, and (c) the indextlist is now a more faithful representation of what the index AM will actually produce, viz. nulls for any non-returnable columns. This is easier to hit since we introduced included columns, but it's possible to construct failing examples without that, as per the added regression test. Hence, back-patch to all supported branches. Per bug #17350 from Louis Jachiet. Discussion: https://postgr.es/m/[email protected] https://git.postgresql.org/pg/commitdiff/4ace456776524839ef3279ab0bad8a2c9f6cc2a7 Amit Kapila pushed: Move index vacuum routines to vacuum.c. An upcoming patch moves parallel vacuum code out of vacuumlazy.c. This code restructuring will allow both lazy vacuum and parallel vacuum to use index vacuum functions. Author: Masahiko Sawada Reviewed-by: Hou Zhijie, Amit Kapila Discussion: https://www.postgresql.org/message-id/20211030212101.ae3qcouatwmy7tbr%40alap3.anarazel.de https://git.postgresql.org/pg/commitdiff/cc8b25712b5ed8809048c7e209882bb0981214d6 Move parallel vacuum code to vacuumparallel.c. This commit moves parallel vacuum related code to a new file commands/vacuumparallel.c so that any table AM supporting indexes can utilize parallel vacuum in order to call index AM callbacks (ambulkdelete and amvacuumcleanup) with parallel workers. Another reason for this refactoring is that the parallel vacuum isn't specific to heap so it doesn't make sense to keep this code in heap/vacuumlazy.c. Author: Masahiko Sawada, based on suggestion from Andres Freund Reviewed-by: Hou Zhijie, Amit Kapila, Haiying Tang Discussion: https://www.postgresql.org/message-id/20211030212101.ae3qcouatwmy7tbr%40alap3.anarazel.de https://git.postgresql.org/pg/commitdiff/8e1fae193864527c931a704bd7908e4fbc983f5c Fix compilation error introduced by commit 8e1fae1938. Author: Masahiko Sawada Discussion: https://postgr.es/m/[email protected] https://git.postgresql.org/pg/commitdiff/94226d4506e66d6e7cbf4b391f1e7393c1962841 Michaël Paquier pushed: Remove assertion for ALTER TABLE .. DETACH PARTITION CONCURRENTLY. One code path related to this flavor of ALTER TABLE was checking that the relation to detach has to be a normal table or a partitioned table, which would fail if using the command with a different relation kind. Views, sequences and materialized views cannot be part of a partition tree, so these would cause the command to fail anyway, but the assertion was triggered. Foreign tables can be part of a partition tree, and again the assertion would have failed. The simplest solution is just to remove this assertion, so as we get the same failure as the non-concurrent code path. While on it, add a regression test in postgres_fdw for the concurrent partition detach of a foreign table, as per a suggestion from Alexander Lakhin. Issue introduced in 71f4c8c. Reported-by: Alexander Lakhin Author: Michael Paquier, Alexander Lakhin Reviewed-by: Peter Eisentraut, Kyotaro Horiguchi Discussion: https://postgr.es/m/[email protected] Backpatch-through: 14 https://git.postgresql.org/pg/commitdiff/2e577c94466fde77d24cd44dc47059cf9cf392a4 Correct comment and some documentation about REPLICA_IDENTITY_INDEX. catalog/pg_class.h was stating that REPLICA_IDENTITY_INDEX with a dropped index is equivalent to REPLICA_IDENTITY_DEFAULT. The code tells a different story, as it is equivalent to REPLICA_IDENTITY_NOTHING. The behavior exists since the introduction of replica identities, and fe7fd4e even added tests for this case but I somewhat forgot to fix this comment. While on it, this commit reorganizes the documentation about replica identities on the ALTER TABLE page, and a note is added about the case of dropped indexes with REPLICA_IDENTITY_INDEX. Author: Michael Paquier, Wei Wang Reviewed-by: Euler Taveira Discussion: https://postgr.es/m/OS3PR01MB6275464AD0A681A0793F56879E759@OS3PR01MB6275.jpnprd01.prod.outlook.com Backpatch-through: 10 https://git.postgresql.org/pg/commitdiff/fc95d35b9429096ec4d028d79dcf1fb8b5d4b16e Fix incorrect field count in pg_control_checkpoint(). 18 columns are generated in this function, but we had enough space for 19 of them. Introduced by 4b0d28d. Author: Bharath Rupireddy Reviewed-by: Justin Pryzby, Euler Taveira Discussion: https://postgr.es/m/CALj2ACVQ=hAs=sT0n4xriimqRrrgECySfg_tSqA+26Rb_yfs2A@mail.gmail.com https://git.postgresql.org/pg/commitdiff/86d9888d2ead04a1a139bbaef9d7f4648022fe4b Bruce Momjian pushed: doc: clarify when expression indexes evaluate their expressions. Only non-HOT updates evaluate the index expression. Reported-by: Chris Lowder Discussion: https://postgr.es/m/[email protected] Backpatch-through: 10 https://git.postgresql.org/pg/commitdiff/e2e1bbde46a3509c3b7e830196f4314242925247 Fujii Masao pushed: postgres_fdw: Allow postgres_fdw.application_name to include escape sequences. application_name that used when postgres_fdw establishes a connection to a foreign server can be specified in either or both a connection parameter of a server object and GUC postgres_fdw.application_name. This commit allows those parameters to include escape sequences that begins with % character. Then postgres_fdw replaces those escape sequences with status information. For example, %d and %u are replaced with user name and database name in local server, respectively. This feature enables us to add information more easily to track remote transactions or queries, into application_name of a remote connection. Author: Hayato Kuroda Reviewed-by: Kyotaro Horiguchi, Masahiro Ikeda, Hou Zhijie, Fujii Masao Discussion: https://postgr.es/m/TYAPR01MB5866FAE71C66547C64616584F5EB9@TYAPR01MB5866.jpnprd01.prod.outlook.com Discussion: https://postgr.es/m/TYCPR01MB5870D1E8B949DAF6D3B84E02F5F29@TYCPR01MB5870.jpnprd01.prod.outlook.com https://git.postgresql.org/pg/commitdiff/6e0cb3dec10e460288d68a128e3d79d16a230cdb postgres_fdw: Revert unstable tests for postgres_fdw.application_name. Commit 6e0cb3dec1 added the tests that check that escape sequences in postgres_fdw.application_name setting are replaced with status information expectedly. But they were unstable and caused some buildfarm members to report the failure. This commit reverts those unstable tests. https://git.postgresql.org/pg/commitdiff/5e64ad369771b66bb3e916aade735defce6e65a1 Thomas Munro pushed: Fix overly generic name in with.sql test. Avoid the name "test". In the 10 branch, this could clash with alter_table.sql, as seen in the build farm. That other instance was already renamed in later branches by commit 2cf8c7aa, but it's good to future-proof the name here too. Back-patch to 10. Reviewed-by: Tom Lane [email protected] Discussion: https://postgr.es/m/CA%2BhUKGJf4RAXUyAYVUcQawcptX%3DnhEco3SYpuPK5cCbA-F1eLA%40mail.gmail.com https://git.postgresql.org/pg/commitdiff/8112bcf0cc602e00e95eab6c4bdc0eb73b5b547d Daniel Gustafsson pushed: Revert b2a459edf "Fix GRANTED BY support in REVOKE ROLE statements". The reverted commit attempted to fix SQL specification compliance for the cases which 6aaaa76bb left. This however broke existing behavior which takes precedence over spec compliance so revert. The introduced tests are left after the revert since the codepath isn't well covered. Per bug report 17346. Backpatch down to 14 where it was introduced. Reported-by: Andrew Bille [email protected] Discussion: https://postgr.es/m/[email protected] https://git.postgresql.org/pg/commitdiff/e68570e388f08c2e36ce7d2a9564941b89db6549 Álvaro Herrera pushed: Small cleanups related to PUBLICATION framework code. Discussion: https://postgr.es/m/[email protected] https://git.postgresql.org/pg/commitdiff/c9105dd3660f4a801e6f87a1ed68189bd30576bf Andres Freund pushed: ci: Add continuous integration for github repositories via cirrus-ci. Currently FreeBSD, Linux, macOS and Windows (Visual Studio) are tested. The main goal of this integration is to make it easier to test in-development patches across multiple platforms. This includes improving the testing done automatically by cfbot [1] for commitfest entries. It is not the goal to supersede the buildfarm. cirrus-ci [2] was chosen because it was already in use for cfbot, allows using full VMs, has good OS coverage and allows accessing the full test results without authentication (like a github account). It might be worth adding support for further CI providers, particularly ones supporting other git forges, in the future. To keep CI times tolerable, most platforms use pre-generated images. Some platforms use containers, others use full VMs. For instructions on how to enable the CI integration in a repository and further details, see src/tools/ci/README [1] http://cfbot.cputube.org/ [2] https://cirrus-ci.org/ Author: Andres Freund [email protected] Author: Thomas Munro [email protected] Author: Melanie Plageman [email protected] Reviewed-By: Melanie Plageman [email protected] Reviewed-By: Justin Pryzby [email protected] Reviewed-By: Thomas Munro [email protected] Reviewed-By: Peter Eisentraut [email protected] Discussion: https://postgr.es/m/[email protected] https://git.postgresql.org/pg/commitdiff/93d97349461347d952e8cebdf62f5aa84b4bd20a Magnus Hagander pushed: Fix typo. Reported-By: Eric Mutta Backpatch-through: 10 Discussion: https://postgr.es/m/[email protected] https://git.postgresql.org/pg/commitdiff/69872d0bbe64fcd67c4fb4c61e5c7bf6a3443a47 [Less]

DynamoDB FDW 1.1.0 released We have just released version 1.1.0 of the Foreign Data Wrapper for DynamoDB. This release can work with PostgreSQL 13 and 14. This release improves following item: Support PostgreSQL 14.0 The FDW supports ... [More] following features : Support SELECT feature to get data from DynamoDB. DynamoDB FDW supports selecting columns or nested attribute object by using -> or ->> jsonb operator. Support INSERT feature. Support UPDATE feature. Support DELETE feature. Support push down WHERE clause (including nested attribute object). Support push down function SIZE of DynamoDB. This is developed by Toshiba Software Engineering & Technology Center. Please see the repository for details. Source repository : https://github.com/pgspider/dynamodb_fdw Best Regards, Shigeo Hirose This email was sent to you from Toshiba. It was delivered on their behalf by the PostgreSQL project. Any questions about the content of the message should be sent to Toshiba. [Less]

I'm pleased to announce the new releases of pg_builder and pg_wrapper packages. The main topic of these releases is support for Postgres 14 and PHP 8.1 pg_builder version 2.0.0 pg_builder is a query builder for Postgres backed by a partial PHP ... [More] reimplementation of PostgreSQL's own SQL parser. It supports almost all syntax available in Postgres 14 for SELECT (and VALUES), INSERT, UPDATE, and DELETE queries. With pg_builder it is possible to start with a manually written query, parse it into an Abstract Syntax Tree, add query parts (either as Node objects or as strings) to this tree or remove them, and finally convert the tree back to an SQL string. Release highlights Support for new syntax of Postgres 14: most of the keywords can be used as column aliases without AS; DISTINCT clause for GROUP BY; SEARCH and CYCLE clauses for Common Table Expressions; alias for USING clause of JOIN expressions. SQL functions with custom argument format (arguments separated by keywords, keywords as arguments, etc) are now parsed to specialized Nodes and will appear in generated SQL the same way they did in source: trim(trailing 'o' from 'foo') rather than pg_catalog.rtrim('foo', 'o'). This follows the changes done in Postgres 14 itself. No E_DEPRECATED errors when running under PHP 8.1 Full release notes The package can be downloaded from Github or installed with Composer: $ composer require sad_spirit/pg_builder pg_builder can be used on its own, using it together with pg_wrapper allows to run the built queries with transparent conversion of query parameters to Postgres types. pg_wrapper version 2.0.0 pg_wrapper provides converters for PostgreSQL data types and an OO wrapper around PHP's native pgsql extension that uses these converters. Conversion of query result fields is done automatically using database metadata, query parameters may require specifying type. For those types where a corresponding native PHP type or class is available it is used (text -> string, timestamp -> DateTimeImmutable, hstore -> associative array, etc.). For other types (geometric types, ranges) the package provides custom classes. Release highlights Full support for multirange types added in Postgres 14, with types\Multirange and its descendants to represent the values on PHP side and converters\containers\MultiRangeConverter to transform the values to and from DB string representation. Support changes to pgsql extension done in PHP 8.1: objects are used instead of resources for connection and query results. Full release notes The package can be downloaded from Github or installed with Composer: $ composer require sad_spirit/pg_wrapper [Less]