La conférence germanophone PostgreSQL Conference 2018 aura lieu le 13 avril 2018 à Berlin. L'appel à conférenciers est ouvert à l'adresse http://2018.pgconf.de/de/callforpapers.html jusqu'au 9 janvier 2018, et le site de la conférence est disponible ici : http://2018.pgconf.de/

Les nouveautés des produits dérivés

Offres d'emplois autour de PostgreSQL en octobre

PostgreSQL Local

PostgreSQL dans les média

PostgreSQL Weekly News / les nouvelles hebdomadaires vous sont offertes cette semaine par David Fetter. Traduction par l'équipe PostgreSQLFr sous licence CC BY-NC-SA. La version originale se trouve à l'adresse suivante : http://www.postgresql.org/message-id/20171030002829.GA6016@fetter.org

Submit news and announcements by Sunday at 3:00pm EST5EDT. Please send English language ones to david@fetter.org, German language to pwn@pgug.de, Italian language to pwn@itpug.org.

Correctifs appliqués

Tom Lane pushed:

  • Adjust psql \d query to avoid use of @> operator. It seems that the parray_gin extension has seen fit to introduce a "text[] @> text[]" operator, which conflicts with the core "anyarray @> anyarray" operator, causing ambiguous-operator failures if the input arguments are coercible to text[] without being exactly that type. This strikes me as a bad idea, but it's out there and people use it. As of v10, that breaks psql's query that tries to test "pg_statistic_ext.stxkind @> '{d}'", since stxkind is char[]. The best workaround seems to be to avoid use of that operator. We can use a scalar-vs-array test "'d' = any(stxkind)" instead; that's arguably more readable anyway. Per report from Justin Pryzby. Backpatch to v10 where this query was added. Discussion: https://postgr.es/m/20171022181525.GA21884@telsasoft.com https://git.postgresql.org/pg/commitdiff/471d55859c11b40059aef7dd82f82b3a0dc338b1
  • Adjust psql \d query to avoid use of @> operator. It seems that the parray_gin extension has seen fit to introduce a "text[] @> text[]" operator, which conflicts with the core "anyarray @> anyarray" operator, causing ambiguous-operator failures if the input arguments are coercible to text[] without being exactly that type. This strikes me as a bad idea, but it's out there and people use it. As of v10, that breaks psql's query that tries to test "pg_statistic_ext.stxkind @> '{d}'", since stxkind is char[]. The best workaround seems to be to avoid use of that operator. We can use a scalar-vs-array test "'d' = any(stxkind)" instead; that's arguably more readable anyway. Per report from Justin Pryzby. Backpatch to v10 where this query was added. Discussion: https://postgr.es/m/20171022181525.GA21884@telsasoft.com https://git.postgresql.org/pg/commitdiff/471d55859c11b40059aef7dd82f82b3a0dc338b1
  • Sync our copy of the timezone library with IANA release tzcode2017c. This is a trivial update containing only cosmetic changes. The point is just to get back to being synced with an official release of tzcode, rather than some ad-hoc point in their commit history, which is where commit 47f849a3c left it. https://git.postgresql.org/pg/commitdiff/24a1897ab92646795bf065aa1b9d266aba74469f
  • Update time zone data files to tzdata release 2017c. DST law changes in Fiji, Namibia, Northern Cyprus, Sudan, Tonga, and Turks & Caicos Islands. Historical corrections for Alaska, Apia, Burma, Calcutta, Detroit, Ireland, Namibia, and Pago Pago. https://git.postgresql.org/pg/commitdiff/8df4ce1eac7835d87d89a4fc4d5d3ae5554f87b7
  • Documentation improvements around domain types. I was a bit surprised to find that domains were almost completely unmentioned in the main SGML documentation, outside of the reference pages for CREATE/ALTER/DROP DOMAIN. In particular, noplace was it mentioned that we don't support domains over composite, making it hard to document the planned fix for that. Hence, add a section about domains to chapter 8 (Data Types). Also, modernize the type system overview in section 37.2; it had never heard of range types, and insisted on calling arrays base types, which seems a bit odd from a user's perspective; furthermore it didn't fit well with the fact that we now support arrays over types other than base types. It seems appropriate to use the term "container types" to describe all of arrays, composites, and ranges, so let's do that. Also a few other minor improvements, notably improve an example query in rowtypes.sgml by using a LATERAL function instead of an ad-hoc OFFSET 0 clause. In part this is mop-up for commit c12d570fa, which missed updating 37.2 to reflect the fact that it added arrays of domains. We could possibly back-patch this without that claim, but I don't feel a strong need to. https://git.postgresql.org/pg/commitdiff/a32c0923b4da7f7df95616aaecbb85ef9f12f93f
  • Documentation improvements around domain types. I was a bit surprised to find that domains were almost completely unmentioned in the main SGML documentation, outside of the reference pages for CREATE/ALTER/DROP DOMAIN. In particular, noplace was it mentioned that we don't support domains over composite, making it hard to document the planned fix for that. Hence, add a section about domains to chapter 8 (Data Types). Also, modernize the type system overview in section 37.2; it had never heard of range types, and insisted on calling arrays base types, which seems a bit odd from a user's perspective; furthermore it didn't fit well with the fact that we now support arrays over types other than base types. It seems appropriate to use the term "container types" to describe all of arrays, composites, and ranges, so let's do that. Also a few other minor improvements, notably improve an example query in rowtypes.sgml by using a LATERAL function instead of an ad-hoc OFFSET 0 clause. In part this is mop-up for commit c12d570fa, which missed updating 37.2 to reflect the fact that it added arrays of domains. We could possibly back-patch this without that claim, but I don't feel a strong need to. https://git.postgresql.org/pg/commitdiff/a32c0923b4da7f7df95616aaecbb85ef9f12f93f
  • Documentation improvements around domain types. I was a bit surprised to find that domains were almost completely unmentioned in the main SGML documentation, outside of the reference pages for CREATE/ALTER/DROP DOMAIN. In particular, noplace was it mentioned that we don't support domains over composite, making it hard to document the planned fix for that. Hence, add a section about domains to chapter 8 (Data Types). Also, modernize the type system overview in section 37.2; it had never heard of range types, and insisted on calling arrays base types, which seems a bit odd from a user's perspective; furthermore it didn't fit well with the fact that we now support arrays over types other than base types. It seems appropriate to use the term "container types" to describe all of arrays, composites, and ranges, so let's do that. Also a few other minor improvements, notably improve an example query in rowtypes.sgml by using a LATERAL function instead of an ad-hoc OFFSET 0 clause. In part this is mop-up for commit c12d570fa, which missed updating 37.2 to reflect the fact that it added arrays of domains. We could possibly back-patch this without that claim, but I don't feel a strong need to. https://git.postgresql.org/pg/commitdiff/a32c0923b4da7f7df95616aaecbb85ef9f12f93f
  • Make setrefs.c match by ressortgroupref even for plain Vars. Previously, we skipped using search_indexed_tlist_for_sortgroupref() if the tlist expression being sought in the child plan node was merely a Var. This is purely an optimization, based on the theory that search_indexed_tlist_for_var() is faster, and one copy of a Var should be as good as another. However, the GROUPING SETS patch broke the latter assumption: grouping columns containing the "same" Var can sometimes have different outputs, as shown in the test case added here. So do it the hard way whenever a ressortgroupref marking exists. (If this seems like a bottleneck, we could imagine building a tlist index data structure for ressortgroupref values, as we do for Vars. But I'll let that idea go until there's some evidence it's worthwhile.) Back-patch to 9.6. The problem also exists in 9.5 where GROUPING SETS came in, but this patch is insufficient to resolve the problem in 9.5: there is some obscure dependency on the upper-planner-pathification work that happened in 9.6. Given that this is such a weird corner case, and no end users have complained about it, it doesn't seem worth the work to develop a fix for 9.5. Patch by me, per a report from Heikki Linnakangas. (This does not fix Heikki's original complaint, just the follow-on one.) Discussion: https://postgr.es/m/aefc657e-edb2-64d5-6df1-a0828f6e9104@iki.fi https://git.postgresql.org/pg/commitdiff/08f1e1f0a47b4b0e87b07b9794698747b279c711
  • Support domains over composite types. This is the last major omission in our domains feature: you can now make a domain over anything that's not a pseudotype. The major complication from an implementation standpoint is that places that might be creating tuples of a domain type now need to be prepared to apply domain_check(). It seems better that unprepared code fail with an error like "<type> is not composite" than that it silently fail to apply domain constraints. Therefore, relevant infrastructure like get_func_result_type() and lookup_rowtype_tupdesc() has been adjusted to treat domain-over-composite as a distinct case that unprepared code won't recognize, rather than just transparently treating it the same as plain composite. This isn't a 100% solution to the possibility of overlooked domain checks, but it catches most places. In passing, improve typcache.c's support for domains (it can now cache the identity of a domain's base type), and rewrite the argument handling logic in jsonfuncs.c's populate_record[set]_worker to reduce duplicative per-call lookups. I believe this is code-complete so far as the core and contrib code go. The PLs need varying amounts of work, which will be tackled in followup patches. Discussion: https://postgr.es/m/4206.1499798337@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/37a795a60b4f4b1def11c615525ec5e0e9449e05
  • Support domains over composite types in PL/Tcl. Since PL/Tcl does little with SQL types internally, this is just a matter of making it work with composite-domain function arguments and results. In passing, make it allow RECORD-type arguments --- that's a trivial change that nobody had bothered with up to now. Discussion: https://postgr.es/m/4206.1499798337@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/820c0305f64507490f00b6220f9175a303c821dd
  • Doc: mention that you can't PREPARE TRANSACTION after NOTIFY. The NOTIFY page said this already, but the PREPARE TRANSACTION page missed it. Discussion: https://postgr.es/m/20171024010602.1488.80066@wrigleys.postgresql.org https://git.postgresql.org/pg/commitdiff/e4fbf22831c2bbcf032ee60a327b871d2364b3f5
  • Rethink the dependencies recorded for FieldSelect/FieldStore nodes. On closer investigation, commits f3ea3e3e8 et al were a few bricks shy of a load. What we need is not so much to lock down the result type of a FieldSelect, as to lock down the existence of the column it's trying to extract. Otherwise, we can break it by dropping that column. The dependency on the result type is then held indirectly through the column, and doesn't need to be recorded explicitly. Out of paranoia, I left in the code to record a dependency on the result type, but it's used only if we can't identify the pg_class OID for the column. That shouldn't ever happen right now, AFAICS, but it seems possible that in future the input node could be marked as being of type RECORD rather than some specific composite type. Likewise for FieldStore. Like the previous patch, back-patch to all supported branches. Discussion: https://postgr.es/m/22571.1509064146@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/6784d7a1dc69d53b7f41eebf62bf7ffd63885294
  • Fix crash when columns have been added to the end of a view. expandRTE() supposed that an RTE_SUBQUERY subquery must have exactly as many non-junk tlist items as the RTE has column aliases for it. This was true at the time the code was written, and is still true so far as parse analysis is concerned --- but when the function is used during planning, the subquery might have appeared through insertion of a view that now has more columns than it did when the outer query was parsed. This results in a core dump if, for instance, we have to expand a whole-row Var that references the subquery. To avoid crashing, we can either stop expanding the RTE when we run out of aliases, or invent new aliases for the added columns. While the latter might be more useful, the former is consistent with what expandRTE() does for composite-returning functions in the RTE_FUNCTION case, so it seems like we'd better do it that way. Per bug #14876 from Samuel Horwitz. This has been busted since commit ff1ea2173 allowed views to acquire more columns, so back-patch to all supported branches. Discussion: https://postgr.es/m/20171026184035.1471.82810@wrigleys.postgresql.org https://git.postgresql.org/pg/commitdiff/d5b760ecb5e172252810fae877e6d6193b818167
  • Dept of second thoughts: keep aliasp_item in sync with tlistitem. Commit d5b760ecb wasn't quite right, on second thought: if the caller didn't ask for column names then it would happily emit more Vars than if the caller did ask for column names. This is surely not a good idea. Advance the aliasp_item whether or not we're preparing a colnames list. https://git.postgresql.org/pg/commitdiff/d76886c2d33123299ce7c8255a71e39b9e53711b
  • Support domains over composite types in PL/Perl. In passing, don't insist on rsi->expectedDesc being set unless we actually need it; this allows succeeding in a couple of cases where PL/Perl functions returning setof composite would have failed before, and makes the error message more apropos in other cases. Discussion: https://postgr.es/m/4206.1499798337@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/60651e4cddbb77e8f1a0c7fc0be6a7e7bf626fe0

Andrew Dunstan pushed:

Michael Meskes pushed:

Robert Haas pushed:

Correctifs en attente

Tom Lane sent in a patch to fix an asymmetry in parse_func.c.

Amit Langote and Tom Lane traded patches to fix an infelicity in joinaliasvars uncovered by sqlsmith.

Álvaro Herrera sent in two revisions of a patch to fix autovacuum work items.

Amit Khandekar sent in two more revisions of a patch to implement UPDATE of partition keys in declaratively partitioned tables so that tuples move to the appropriate partition as needed.

Doug Rady sent in another revision of a patch to pgbench which adds an option to build using ppoll() for larger connection counts.

Ivan Kartyshov sent in three more revisions of a patch to make async subscribers to wait for lsn to be replayed.

Amit Langote sent in five more revisions of a patch to prune partitions faster.

Álvaro Herrera sent in two more revisions of a patch to enable indexes on partitions to be unique.

Thomas Munro sent in two more revisions of a patch to implement parallel hash.

Anthony Bykov sent in a patch to add a JSONB TRANSFORM for PL/Perl.

Simon Riggs sent in a patch to remove the code that maintained two checkpoint's WAL files and all associated stuff.

Masahiko Sawada sent in another revision of a patch to allow atomic commits on foreign servers.

Amul Sul sent in two more revisions of a patch to add hash partitioning.

Anthony Bykov sent in a patch to create a JSONB TRANSFORM for PL/Python2U.

Tomas Vondra sent in two revisions of a patch to implement BRIN multi-range indexes.

Michaël Paquier sent in three revisions of a patch to implement pg_receivewal --no-sync.

Jing Wang sent in a patch to support unicode host variables in ECPG.

Gao Zengqi (高增琦) sent in a patch to fix an endless loop in ECPG in informix mode.

Petr Jelínek sent in a patch to prevent resetting additional columns on the logical subscriber to NULL after UPDATE. When the subscriber's table had extra columns, this was happening, and was usually the wrong thing.

Rushabh Lathia sent in another revision of a patch to add parallel B-tree index build sorting.

Masahiko Sawada sent in another revision of a patch to move relation extension locks out of the heavyweight lock manager.

Michaël Paquier sent in a patch to place the timeline ID in the backup_label file.

Kyotaro HORIGUCHI sent in another revision of a patch to enable switching WAL source in the midst of a record.

Etsuro Fujita sent in two more revisions of a patch to add support for tuple routing to foreign partitions.

Peter Eisentraut sent in a patch to convert ids to upper case at build time.

Yura Sokolov sent in two more revisions of a patch to implement logical decoding of two-phase transactions.

Lætitia Avrot sent in a patch to add a table_constraint description to the ALTER TABLE synopsis.

Andrey Borodin sent in two revisions of a patch to add index-only scan for cube and seg.

Peter Eisentraut sent in another revision of a patch to replace hand-tooled boolean handling with stdbool.h.

Robert Haas sent in another revision of a patch to enable libpq protocol negotiation.

Jeevan Chalke sent in another revision of a patch to implement partition-wise aggregation/grouping.

Takayuki Tsunakawa sent in two revisions of a patch to fix a startup crash on Windows.

Julien Rouhaud sent in a patch to fix unsafe tuple releasing in get_default_partition_oid.

Pavel Stěhule sent in a patch to enable psql to take sorting arguments for some of its \ commands.

Chris Travers sent in a patch to restrict pg_rewind to data/wal directories.

Amit Kapila sent in another revision of a patch to make extern params parallel safe.

Amit Kapila sent in another revision of a patch to fix role handling in parallel workers.

Nikolay Shaplov sent in a patch to better document some regression tests for reloptions.

Dmitry Dolgov sent in another revision of a patch to implement generic type subscripting.