PostgreSQL La base de donnees la plus sophistiquee au monde.

Twitter


Utilisateur




Langue

Traductions de cette page:




Nouvelles hebdomadaires de PostgreSQL - 20 février 2011

Les nouveautés des produits dérivés

Offres d'emplois autour de PostgreSQL en février

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.

Proposez vos articles ou annonces avant dimanche 15:00 (heure du Pacifique). Merci de les envoyer en anglais à david (a) fetter.org, en allemand à pwn (a) pgug.de, en italien à pwn (a) itpug.org et en espagnol à pwn (a) arpug.com.ar.

(lien vers l'article original)

Revues de code

Correctifs appliqués

Bruce Momjian a poussé :

Tom Lane a poussé :

  • Change the naming convention for extension files to use double dashes. This allows us to have an unambiguous rule for deconstructing the names of script files and secondary control files, without having to forbid extension and version names from containing any dashes. We do have to forbid them from containing double dashes or leading/trailing dashes, but neither restriction is likely to bother anyone in practice. Per discussion, this seems like a better solution overall than the original design. http://git.postgresql.org/pg/commitdiff/27d5d7ab10086d833e3df251951cf63c392b8bca
  • Convert contrib modules to use the extension facility. This isn't fully tested as yet, in particular I'm not sure that the "foo--unpackaged--1.0.sql" scripts are OK. But it's time to get some buildfarm cycles on it. sepgsql is not converted to an extension, mainly because it seems to require a very nonstandard installation process. Dimitri Fontaine and Tom Lane. http://git.postgresql.org/pg/commitdiff/629b3af27d5c2bc9d6e16b22b943ad651d4ecb56
  • Avoid use of CREATE OR REPLACE FUNCTION in extension installation files. It was never terribly consistent to use OR REPLACE (because of the lack of comparable functionality for data types, operators, etc), and experimentation shows that it's now positively pernicious in the extension world. We really want a failure to occur if there are any conflicts, else it's unclear what the extension-ownership state of the conflicted object ought to be. Most of the time, CREATE EXTENSION will fail anyway because of conflicts on other object types, but an extension defining only functions can succeed, with bad results. http://git.postgresql.org/pg/commitdiff/029fac2264101919b65fb6319bb994f941969471
  • Assorted fixups for "unpackaged" conversion scripts. From first pass of testing. Notably, there seems to be no need for adminpack--unpackaged--1.0.sql because none of the objects that the old module creates would ever be dumped by pg_dump anyway (they are all in pg_catalog). http://git.postgresql.org/pg/commitdiff/3b61e57f3c352ab97c6514898d46480b5725ebb9
  • Support replacing MODULE_PATHNAME during extension script file execution. This avoids the need to find a way to make PGXS' .sql.in-to-.sql rule insert the right thing. We'll just deprecate use of that hack for extensions. http://git.postgresql.org/pg/commitdiff/e693e97d754ed6812ea115170afeae4bf8797d3f
  • More fixups for "unpackaged" conversion scripts. http://git.postgresql.org/pg/commitdiff/de06cfe834dfff283deddfe1eb2945ba8a4fde2a
  • Remove no-longer-needed special case hacks in MSVC build scripts. http://git.postgresql.org/pg/commitdiff/2ee69ff65de6e8626784d4a263953158ef480ab4
  • Fix obsolete references to old-style contrib installation methods. http://git.postgresql.org/pg/commitdiff/f1fb4b0e63a677cdc86de667c75142b88a4edb65
  • Small improvements to external-projects documentation. http://git.postgresql.org/pg/commitdiff/cee103da14f470d29c47827b810da44cdab2a0d2
  • Rearrange extension-related views as per recent discussion. The original design of pg_available_extensions did not consider the possibility of version-specific control files. Split it into two views: pg_available_extensions shows information that is generic about an extension, while pg_available_extension_versions shows all available versions together with information that could be version-dependent. Also, add an SRF pg_extension_update_paths() to assist in checking that a collection of update scripts provide sane update path sequences. http://git.postgresql.org/pg/commitdiff/555353c0c59ada35ae59c8a76186e98d123fa8b3
  • Fix MSVC build scripts for recent extension-related changes. Untested, but we'll soon see if the buildfarm likes this. http://git.postgresql.org/pg/commitdiff/01ff8dd7560f2647dccc3d70f713dd6b27bf843e
  • Rethink naming of contrib/intagg extension. Initially it was called int_aggregate after the old SQL file, but since the documentation just says "intagg" and that's also the directory name, let's conform to that instead. http://git.postgresql.org/pg/commitdiff/74883d33730ecb69e6f4142deb8c5882af127b32
  • Fix obsolete comment. Comment about MaxAllocSize was not updated when the TOAST-header macros were replaced in 8.3 "varvarlena" changes. Per report from Frederik Ramm. http://git.postgresql.org/pg/commitdiff/887dd041a65006deeaf514f78e4a5012dc6f7f7c
  • Bring hstore's comment into line with style of other contrib comments. All the other ones that are primarily a new datatype say "data type for <purpose>", so make this one similar. http://git.postgresql.org/pg/commitdiff/f5fc1de501d03f6399670dd16989c5925b9191d2
  • Add CheckTableNotInUse calls in DROP TABLE and DROP INDEX. Recent releases had a check on rel->rd_refcnt in heap_drop_with_catalog, but failed to cover the possibility of pending trigger events at DROP time. (Before 8.4 we didn't even check the refcnt.) When the trigger events were eventually fired, you'd get "could not open relation with OID nnn" errors, as in recent report from strk. Better to throw a suitable error when the DROP is attempted. Also add a similar check in DROP INDEX. Back-patch to all supported branches. http://git.postgresql.org/pg/commitdiff/eff027c43288d15307676b1bd4736ab11f34c407
  • Fix corner case for binary upgrade: extension functions in pg_catalog. Normally, pg_dump summarily excludes functions in pg_catalog from consideration. However, some extensions may create functions in pg_catalog (adminpack already does that, and extensions for procedural languages will likely do it too). In binary-upgrade mode, we have to dump such functions, or the extension will be incomplete after upgrading. Per experimentation with adminpack. http://git.postgresql.org/pg/commitdiff/89c29c033154b717b16db2ee3c87bdec4393b0d4
  • Add FOREACH IN ARRAY looping to plpgsql. (I'm not entirely sure that we've finished bikeshedding the syntax details, but the functionality seems OK.) Pavel Stehule, reviewed by Stephen Frost and Tom Lane. http://git.postgresql.org/pg/commitdiff/6e02755b22ea62775c906d29b87b55b38ab70bd2
  • Make a no-op ALTER EXTENSION UPDATE give just a NOTICE, not ERROR. This seems a bit more user-friendly. http://git.postgresql.org/pg/commitdiff/65076269ea54a8cd6e39f066a208c7d13aceac0a
  • Add backwards-compatible declarations of some core GIN support functions. These are needed to support reloading dumps of 9.0 installations containing contrib/intarray or contrib/tsearch2. Since not only regular dump/reload but binary upgrade would fail, it seems worth the trouble to carry these stubs for awhile. Note that the contrib opclasses referencing these functions will still work fine, since GIN doesn't actually pay any attention to the declared signature of a support function. http://git.postgresql.org/pg/commitdiff/6595dd04d136d5c97ae05fc580572c8f00042143
  • Fix bogus test for hypothetical indexes in get_actual_variable_range(). That function was supposing that indexoid == 0 for a hypothetical index, but that is not likely to be true in any non-toy implementation of an index adviser, since assigning a fake OID is the only way to know at EXPLAIN time which hypothetical index got selected. Fix by adding a flag to IndexOptInfo to mark hypothetical indexes. Back-patch to 9.0 where get_actual_variable_range() was added. Gurjeet Singh http://git.postgresql.org/pg/commitdiff/a2095f7fb5a57ea1794f25d029756d9a140fd429
  • Fix blatantly uninitialized variable in recent commit. Doesn't anybody around here pay attention to compiler warnings? http://git.postgresql.org/pg/commitdiff/93016983d1e8f3aeb508f1be8daf5ca5de5c5b61
  • Fix contrib/pg_trgm to have smoother updates from 9.0. Take care of some loose ends in the update-from-unpackaged script, and apply some ugly hacks to ensure that it produces the same catalog state as the fresh-install script. Per discussion, this seems like a safer plan than having two different catalog states that both call themselves "pg_trgm 1.0", even if it's not immediately clear that the subtle differences would ever matter. Also, fix the stub function gin_extract_trgm() so that it works instead of just bleating. Needed because this function will get called during a regular dump and reload, if there are any indexes using its opclass. The user won't have an opportunity to update the extension till later, so telling him to do so is unhelpful. http://git.postgresql.org/pg/commitdiff/4eb49db7ae634fab9af7437b2e7b6388dfd83bd3
  • Fix upgrade of contrib/btree_gist from 9.0. The initial version of the update-from-unpackaged script neglected to include the <> operators that were added to the opclasses during 9.1. To make this script produce the same final state as the regular install script, use the same ALTER OPERATOR FAMILY trick as in pg_trgm. http://git.postgresql.org/pg/commitdiff/ec65a79db2a423a156cda8e862d34052d7175a86
  • Fix upgrade of contrib/intarray and contrib/unaccent from 9.0. Take care of a couple of discrepancies between what you get from a fresh install and what the first-draft update-from-unpackaged scripts produced. http://git.postgresql.org/pg/commitdiff/0024e348989254d48dc4afe9beab98a6994a791e
  • Fix upgrade of contrib/xml2 from 9.0. Update script was being sloppy about two functions that have been changed since 9.0. http://git.postgresql.org/pg/commitdiff/de623f33353c96657651f9c3a6c8756616c610e4
  • Fix tsmatchsel() to account properly for null rows. ts_typanalyze.c computes MCE statistics as fractions of the non-null rows, which seems fairly reasonable, and anyway changing it in released versions wouldn't be a good idea. But then ts_selfuncs.c has to account for that. Failure to do so results in overestimates in columns with a significant fraction of null documents. Back-patch to 8.4 where this stuff was introduced. Jesper Krogh http://git.postgresql.org/pg/commitdiff/52b60530f257b1591d8b72264cd6c0dd9aabfd46
  • One more hack to make contrib upgrades from 9.0 match fresh 9.1 installs. intarray and tsearch2 both reference core support functions in their GIN opclasses, and the signatures of those functions changed for 9.1. We added backwards-compatible pg_proc entries for the functions in order to allow 9.0 dump files to be restored at all, but that hack leaves the opclasses pointing at pg_proc entries different from what they'd point to if the contrib modules were installed fresh in 9.1. To forestall any possibility of future problems, fix the opclasses to match fresh installs via the expedient of direct UPDATEs on pg_amproc in the update-from-unpackaged scripts. (Yech ... but the alternatives are worse, or require far more effort than seems justified right now.) Note: updating pg_amproc is sufficient because there will be no pg_depend entries corresponding to these dependencies, since the referenced functions are all pinned. http://git.postgresql.org/pg/commitdiff/472f608e436a41865b795c999bda3369725fa097
  • Fix parallel pg_restore to handle comments on POST_DATA items correctly. The previous coding would try to process all SECTION_NONE items in the initial sequential-restore pass, which failed if they were dependencies of not-yet-restored items. Fix by postponing such items into the parallel processing pass once we have skipped any non-PRE_DATA item. Back-patch into 9.0; the original parallel-restore coding in 8.4 did not have this bug, so no need to change it. Report and diagnosis by Arnd Hannemann. http://git.postgresql.org/pg/commitdiff/4cff100d7378b65ded116c5a9960584c351e5fa9
  • Un-break building with BTREE_BUILD_STATS. This has been broken for awhile, but not clear it's worth back-patching. Euler Taveira de Oliveira http://git.postgresql.org/pg/commitdiff/82220e883236c214d670c3f14d943690aa78bc17
  • Create the catalog infrastructure for foreign-data-wrapper handlers. Add a fdwhandler column to pg_foreign_data_wrapper, plus HANDLER options in the CREATE FOREIGN DATA WRAPPER and ALTER FOREIGN DATA WRAPPER commands, plus pg_dump support for same. Also invent a new pseudotype fdw_handler with properties similar to language_handler. This is split out of the "FDW API" patch for ease of review; it's all stuff we will certainly need, regardless of any other details of the FDW API. FDW handler functions will not actually get called yet. In passing, fix some omissions and infelicities in foreigncmds.c. Shigeru Hanada, Jan Urbanski, Heikki Linnakangas http://git.postgresql.org/pg/commitdiff/327e0250716f12fe94b62669d25e572b40a8fba5
  • Implement an API to let foreign-data wrappers actually be functional. This commit provides the core code and documentation needed. A contrib module test case will follow shortly. Shigeru Hanada, Jan Urbanski, Heikki Linnakangas http://git.postgresql.org/pg/commitdiff/bb742407947ad1cbf19355d24282380d576e7654
  • Add contrib/file_fdw foreign-data wrapper for reading files via COPY. This is both very useful in its own right, and an important test case for the core FDW support. This commit includes a small refactoring of copy.c to expose its option checking code as a separately callable function. The original patch submission duplicated hundreds of lines of that code, which seemed pretty unmaintainable. Shigeru Hanada, reviewed by Itagaki Takahiro and Tom Lane http://git.postgresql.org/pg/commitdiff/7c5d0ae7078456bfeedb2103c45b9a32285c2631
  • Minor logic fix for new levenshtein implementation. Alexander Korotkov http://git.postgresql.org/pg/commitdiff/087bd179e63f199105dabc8be0c8aebd087a178e

Simon Riggs a poussé :

Robert Haas a poussé :

Peter Eisentraut a poussé :

Alvaro Herrera a poussé :

ITAGAKI Takahiro a poussé :

Magnus Hagander a poussé :

Correctifs rejetés (à ce jour)

  • Pas de déception cette semaine :-)

Correctifs en attente

  • ITAGAKI Takahiro sent in another revision of the patch to implement MULTISET.
  • Stephen Frost and Robert Haas traded revisions of the patch to allow logging the current role.
  • Marti Raudsepp sent in another revision of the patch which makes it so a key lock is only acquired for columns that can be referenced.
  • Heikki Linnakangas sent in another revision of the patch to add a FDW API for SQL/MED.
  • Thom Brown sent in a patch to make array_cat consistent with the || operator for arrays with respect to NULLs.
  • ITAGAKI Takahiro sent in another revision of the patch to implement transaction-scope advisory locks.
  • Kevin Grittner sent in two revisions of a patch to fix an issue with uninitialized structures from the SSI patch.
  • ITAGAKI Takahiro sent in another revision of the COPY ENCODING patch.
  • Per feedback from Heikki Linnakangas, Simon Riggs sent in a patch to add a server_name parameter, plus mechanism to send info from standby to master. This will help with synchronous replication.
  • YAMAMOTO Takashi sent in a patch to fix an issue with SSI.
  • Tom Lane sent in two versions of a patch to fix pg_tgrm's update-from-unpackaged script.
  • Mark Kirkwood sent in a WIP patch to allow the backend to constrain temporary file space.
  • Tom Lane sent in a WIP patch to update KNN-GiST.
  • Magnus Hagander sent in another revision of the patch to include pg_basebackup.
  • Robert Haas sent in a patch to fix an issue with an assertion failure on UNLOGGED VIEWs.
  • Simon Riggs sent in a patch to add server_name for synchronous replication.
  • Simon Riggs sent in anothre revision of the patch to allow for synchronous replication.
  • Radoslaw Smogura sent in a patch to add void_send and void_receive, used in COPY ... BINARY.

 
pgwn/20_fevrier_2011.txt · Dernière modification: 2011/02/28 02:54 par buggy