| Commit message (Collapse) | Author | Age | |
|---|---|---|---|
| * | Guard against null arguments in binary_upgrade_create_empty_extension(). | Tom Lane | 2016-01-03 |
| | | | | | | | | | | | | | | The CHECK_IS_BINARY_UPGRADE macro is not sufficient security protection if we're going to dereference pass-by-reference arguments before it. But in any case we really need to explicitly check PG_ARGISNULL for all the arguments of a non-strict function, not only the ones we expect null values for. Oversight in commits 30982be4e5019684e1772dd9170aaa53f5a8e894 and f92fc4c95ddcc25978354a8248d3df22269201bc. Found by Andreas Seltenreich. (The other usages in pg_upgrade_support.c seem safe.) | ||
| * | pgindent run for 9.5 | Bruce Momjian | 2015-05-23 |
| | | |||
| * | Integrate pg_upgrade_support module into backend | Peter Eisentraut | 2015-04-14 |
| Previously, these functions were created in a schema "binary_upgrade", which was deleted after pg_upgrade was finished. Because we don't want to keep that schema around permanently, move them to pg_catalog but rename them with a binary_upgrade_... prefix. The provided functions are only small wrappers around global variables that were added specifically for pg_upgrade use, so keeping the module separate does not create any modularity. The functions still check that they are only called in binary upgrade mode, so it is not possible to call these during normal operation. Reviewed-by: Michael Paquier <michael.paquier@gmail.com> | |||
 |
index : postgresql | |
| postgresql mirror |
| aboutsummaryrefslogtreecommitdiff |