aboutsummaryrefslogtreecommitdiff
path: root/doc/src
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2012-05-11 15:22:30 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2012-05-11 15:22:30 -0400
commit63fecc91770f3d494b6fe993bdc198a9faf6fe2d (patch)
tree6ecee815fbcb1ad27d000669d993c873ca229ae4 /doc/src
parent1331cc6c1ad2beba7985523508d6722dc865c337 (diff)
downloadpostgresql-63fecc91770f3d494b6fe993bdc198a9faf6fe2d.tar.gz
postgresql-63fecc91770f3d494b6fe993bdc198a9faf6fe2d.zip
Fix contrib/citext's upgrade script to handle array and domain cases.
We previously recognized that citext wouldn't get marked as collatable during pg_upgrade from a pre-9.1 installation, and hacked its create-from-unpackaged script to manually perform the necessary catalog adjustments. However, we overlooked the fact that domains over citext, as well as the citext[] array type, need the same adjustments. Extend the script to handle those cases. Also, the documentation suggested that this was only an issue in pg_upgrade scenarios, which is quite wrong; loading any dump containing citext from a pre-9.1 server will also result in the type being wrongly marked. I approached the documentation problem by changing the 9.1.2 release note paragraphs about this issue, which is historically inaccurate. But it seems better than having the information scattered in multiple places, and leaving incorrect info in the 9.1.2 notes would be bad anyway. We'll still need to mention the issue again in the 9.1.4 notes, but perhaps they can just reference 9.1.2 for fix instructions. Per report from Evan Carroll. Back-patch into 9.1.
Diffstat (limited to 'doc/src')
-rw-r--r--doc/src/sgml/release-9.1.sgml16
1 files changed, 11 insertions, 5 deletions
diff --git a/doc/src/sgml/release-9.1.sgml b/doc/src/sgml/release-9.1.sgml
index ca53f5fc7d2..9fb9fb7908a 100644
--- a/doc/src/sgml/release-9.1.sgml
+++ b/doc/src/sgml/release-9.1.sgml
@@ -667,10 +667,13 @@
</para>
<para>
- Also, if your installation was upgraded from a previous major release
- by running <application>pg_upgrade</>, and it contains table columns of
- the <type>citext</> data type, you should run <literal>CREATE EXTENSION
- citext FROM unpackaged</>. If you've already done that before
+ Also, if you use the <type>citext</> data type, and you upgraded
+ from a previous major release by running <application>pg_upgrade</>,
+ you should run <literal>CREATE EXTENSION citext FROM unpackaged</>
+ to avoid collation-related failures in <type>citext</> operations.
+ The same is necessary if you restore a dump from a pre-9.1 database
+ that contains an instance of the <type>citext</> data type.
+ If you've already run the <command>CREATE EXTENSION</> command before
upgrading to 9.1.2, you will instead need to do manual catalog updates
as explained in the second changelog item.
</para>
@@ -717,7 +720,9 @@
<para>
Existing <type>citext</> columns and indexes aren't correctly marked as
being of a collatable data type during <application>pg_upgrade</> from
- a pre-9.1 server. That leads to operations on them failing with errors
+ a pre-9.1 server, or when a pre-9.1 dump containing the <type>citext</>
+ type is loaded into a 9.1 server.
+ That leads to operations on these columns failing with errors
such as <quote>could not determine which collation to use for string
comparison</>. This change allows them to be fixed by the same
script that upgrades the <type>citext</> module into a proper 9.1
@@ -732,6 +737,7 @@
<filename><replaceable>SHAREDIR</>/extension/citext--unpackaged--1.0.sql</filename>.
(Run <literal>pg_config --sharedir</> if you're uncertain where
<replaceable>SHAREDIR</> is.)
+ There is no harm in doing this again if unsure.
</para>
</listitem>