PostgreSQL 9.1.6 commit log

Stamp 9.1.6.

  
commit   : 04a37a5716867f8eade144baac847a9737ac22f5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 Sep 2012 17:50:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 Sep 2012 17:50:31 -0400    

Click here for diff

  
  

Update release notes for 9.2.1, 9.1.6, 9.0.10, 8.4.14, 8.3.21.

  
commit   : 793664d0c89a21976228cb5520cd05e0cdef463c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 Sep 2012 17:38:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 Sep 2012 17:38:53 -0400    

Click here for diff

  
  

Update time zone data files to tzdata release 2012f.

  
commit   : 1dd03b533004e41bc2c1f98ec91465d784c8536c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 Sep 2012 10:44:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 Sep 2012 10:44:45 -0400    

Click here for diff

  
DST law changes in Fiji.  
  

Translation updates

  
commit   : d4e1ca27c614b862e959d30f413981aa2c9cc699    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 19 Sep 2012 00:03:54 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 19 Sep 2012 00:03:54 -0400    

Click here for diff

  
  

pg_upgrade: Remove check for pg_config

  
commit   : 67503753a7b6690f330d6c663515e5795c40433b    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 18 Sep 2012 21:53:34 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 18 Sep 2012 21:53:34 -0400    

Click here for diff

  
It is no longer used, but was still being checked for.  
  
bug #7548 from Reinhard Max  
  

Provide adequate documentation of the “table_name *” notation.

  
commit   : 34405830517e2a4e5c3ab3f68cf3435f193944ae    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Sep 2012 14:59:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Sep 2012 14:59:38 -0400    

Click here for diff

  
Somewhere along the line, somebody decided to remove all trace of this  
notation from the documentation text.  It was still in the command syntax  
synopses, or at least some of them, but with no indication what it meant.  
This will not do, as evidenced by the confusion apparent in bug #7543;  
even if the notation is now unnecessary, people will find it in legacy  
SQL code and need to know what it does.  
  

Fix bufmgr so CHECKPOINT_END_OF_RECOVERY behaves as a shutdown checkpoint. Recovery code documents clearly that a shutdown checkpoint is executed at end of recovery - a shutdown checkpoint WAL record is written but the buffer manager had been altered to treat end of recovery as a normal checkpoint. This bug exacerbates the bufmgr relpersistence bug.

  
commit   : 25560fdeb26f75b50793a56f69f64daab4ad586e    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Sun, 16 Sep 2012 19:55:27 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Sun, 16 Sep 2012 19:55:27 +0100    

Click here for diff

  
Bug spotted by Andres Freund, patch by me.  
  

Fix documentation reference to maximum allowed for autovacuum_freeze_max_age.

  
commit   : 5752e1bbb2d9f553fd6211fbb47ab2b240d740f0    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Sun, 16 Sep 2012 12:20:35 -0500    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Sun, 16 Sep 2012 12:20:35 -0500    

Click here for diff

  
The documentation mentioned setting autovacuum_freeze_max_age to  
"its maximum allowed value of a little less than two billion".  
This led to a post asking about the exact maximum allowed value,  
which is precisely two billion, not "a little less".  
  
Based on question by Radovan Jablonovsky.  Backpatch to 8.3.  
  

Back-patch fix and test case for bug #7516.

  
commit   : 87802a12d7706221a46961b1def076c5fc99e46e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 14 Sep 2012 11:50:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 14 Sep 2012 11:50:06 -0400    

Click here for diff

  
Back-patch commits 9afc6481117d2dd936e752da0424a2b6b05f6459 and  
b8fbbcf37f22c5e8361da939ad0fc4be18a34ca9.  The first of these is really  
a minor code cleanup to save a few cycles, but it turns out to provide  
a workaround for the misoptimization problem described in bug #7516.  
The second commit adds a regression test case.  
  
Back-patch the fix to all active branches.  The test case only works  
as far back as 9.0, because it relies on plpgsql which isn't installed  
by default before that.  (I didn't have success modifying it into an  
all-plperl form that still provoked a crash, though this may just reflect  
my lack of Perl-fu.)  
  

Properly set relpersistence for fake relcache entries.

  
commit   : fef2c17807e095a04441e4f1fe05f75d5578ead2    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 14 Sep 2012 09:35:07 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 14 Sep 2012 09:35:07 -0400    

Click here for diff

  
This can result in buffers failing to be properly flushed at  
checkpoint time, leading to data loss.  
  
Report, diagnosis, and patch by Jeff Davis.  
  

Fix typo: lexemes misspelled in full text search docs.

  
commit   : df4234d7a9a522073712138da422836e5a637671    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Wed, 12 Sep 2012 07:41:55 -0500    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Wed, 12 Sep 2012 07:41:55 -0500    

Click here for diff

  
Dan Scott  
  
Backpatch original commit 4bc0d2e2cfa8ac523524dccf6f849989c6739083  
to 9.1  
  

Fix logical errors in tsquery selectivity estimation for prefix queries.

  
commit   : bd371ea5c0a119ce6959099a41a95844b33e2beb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 11 Sep 2012 21:23:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 11 Sep 2012 21:23:20 -0400    

Click here for diff

  
I made multiple errors in commit 97532f7c29468010b87e40a04f8daa3eb097f654,  
stemming mostly from failure to think about the available frequency data  
as being element frequencies not value frequencies (so that occurrences of  
different elements are not mutually exclusive).  This led to sillinesses  
such as estimating that "word" would match more rows than "word:*".  
  
The choice to clamp to a minimum estimate of DEFAULT_TS_MATCH_SEL also  
seems pretty ill-considered in hindsight, as it would frequently result in  
an estimate much larger than the available data suggests.  We do need some  
sort of clamp, since a pattern not matching any of the MCELEMs probably  
still needs a selectivity estimate of more than zero.  I chose instead to  
clamp to at least what a non-MCELEM word would be estimated as, preserving  
the property that "word:*" doesn't get an estimate less than plain "word",  
whether or not the word appears in MCELEM.  
  
Per investigation of a gripe from Bill Martin, though I suspect that his  
example case actually isn't even reaching the erroneous code.  
  
Back-patch to 9.1 where this code was introduced.  
  

Make plperl safe against functions that are redefined while running.

  
commit   : ef06dca97504cda3cff852314532338c86d3ccc5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 9 Sep 2012 20:33:03 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 9 Sep 2012 20:33:03 -0400    

Click here for diff

  
validate_plperl_function() supposed that it could free an old  
plperl_proc_desc struct immediately upon detecting that it was stale.  
However, if a plperl function is called recursively, this could result  
in deleting the struct out from under an outer invocation, leading to  
misbehavior or crashes.  Add a simple reference-count mechanism to  
ensure that such structs are freed only when the last reference goes  
away.  
  
Per investigation of bug #7516 from Marko Tiikkaja.  I am not certain  
that this error explains his report, because he says he didn't have  
any recursive calls --- but it's hard to see how else it could have  
crashed right there.  In any case, this definitely fixes some problems  
in the area.  
  
Back-patch to all active branches.  
  

Use .NOTPARALLEL in ecpg/Makefile to avoid a gmake parallelism bug.

  
commit   : 1e214507e5b5d604ea8d8d4e7e564b673df8c8e0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 9 Sep 2012 15:08:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 9 Sep 2012 15:08:32 -0400    

Click here for diff

  
Investigation shows that some intermittent build failures in ecpg are the  
result of a gmake bug that was reported quite some time ago:  
http://savannah.gnu.org/bugs/?30653  
  
Preventing parallel builds of the ecpg subdirectories seems to dodge the  
bug.  Per yesterday's pgsql-hackers discussion, there are some other things  
in the subdirectory makefiles that seem rather unsafe for parallel builds  
too, but there's little point in fixing them as long as we have to work  
around a make bug.  
  
Back-patch to 9.1; parallel builds weren't very well supported before  
that anyway.  
  

Fix PARAM_EXEC assignment mechanism to be safe in the presence of WITH.

  
commit   : ff0b18cc4979d518490dc267e2038daae6030b61    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 7 Sep 2012 20:38:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 7 Sep 2012 20:38:35 -0400    

Click here for diff

  
The planner previously assumed that parameter Vars having the same absolute  
query level, varno, and varattno could safely be assigned the same runtime  
PARAM_EXEC slot, even though they might be different Vars appearing in  
different subqueries.  This was (probably) safe before the introduction of  
CTEs, but the lazy-evalution mechanism used for CTEs means that a CTE can  
be executed during execution of some other subquery, causing the lifespan  
of Params at the same syntactic nesting level as the CTE to overlap with  
use of the same slots inside the CTE.  In 9.1 we created additional hazards  
by using the same parameter-assignment technology for nestloop inner scan  
parameters, but it was broken before that, as illustrated by the added  
regression test.  
  
To fix, restructure the planner's management of PlannerParamItems so that  
items having different semantic lifespans are kept rigorously separated.  
This will probably result in complex queries using more runtime PARAM_EXEC  
slots than before, but the slots are cheap enough that this hardly matters.  
Also, stop generating PlannerParamItems containing Params for subquery  
outputs: all we really need to do is reserve the PARAM_EXEC slot number,  
and that now only takes incrementing a counter.  The planning code is  
simpler and probably faster than before, as well as being more correct.  
  
Per report from Vik Reykja.  
  
Back-patch of commit 46c508fbcf98ac334f1e831d21021d731c882fbb into all  
branches that support WITH.  
  

Fix “too many arguments” messages not to index off the end of argv[].

  
commit   : e40b20a3686d2f8f2d8b5f1d82a6b36717d4ab1d    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 6 Sep 2012 15:43:46 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 6 Sep 2012 15:43:46 -0400    

Click here for diff

  
This affects initdb, clusterdb, reindexdb, and vacuumdb in master  
and 9.2; in earlier branches, only initdb is affected.  
  

Fix inappropriate error messages for Hot Standby misconfiguration errors.

  
commit   : 18730f8d4739468d668322f5ca0a0d6022df6fe6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 Sep 2012 21:49:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 Sep 2012 21:49:14 -0400    

Click here for diff

  
Give the correct name of the GUC parameter being complained of.  
Also, emit a more suitable SQLSTATE (INVALID_PARAMETER_VALUE,  
not the default INTERNAL_ERROR).  
  
Gurjeet Singh, errcode adjustment by me  
  

Fix line end mishandling in pg_upgrade on Windows.

  
commit   : 26f4fc01849b23d0541722d7cfdbd08739f81e1c    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 5 Sep 2012 17:49:09 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 5 Sep 2012 17:49:09 -0400    

Click here for diff

  
pg_upgrade opened the output from pg_dumpall in text mode and  
wrote the split files in text mode. This caused unwanted eating  
of intended carriage returns on input and production of spurious  
carriage returns on output. To avoid this, open all these files  
in binary mode. On non-Windows platforms, this change has no  
effect.  
  
Backpatch to 9.0. On 9.0 and 9.1, we also switch from redirecting  
pg_dumpall's output to using pg_dumpall's -f switch, for the same  
reason.  
  

Restore SIGFPE handler after initializing PL/Perl.

  
commit   : 5ee0f03727eb7452ad8ecbca660d500ab78ac015    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 Sep 2012 16:43:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 Sep 2012 16:43:45 -0400    

Click here for diff

  
Perl, for some unaccountable reason, believes it's a good idea to reset  
SIGFPE handling to SIG_IGN.  Which wouldn't be a good idea even if it  
worked; but on some platforms (Linux at least) it doesn't work at all,  
instead resulting in forced process termination if the signal occurs.  
Given the lack of other complaints, it seems safe to assume that Perl  
never actually provokes SIGFPE and so there is no value in the setting  
anyway.  Hence, reset it to our normal handler after initializing Perl.  
  
Report, analysis and patch by Andres Freund.  
  

Indent fix_path_separator() header properly.

  
commit   : a69b7a1c34750f37c72acaac941555c70050dc7d    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 3 Sep 2012 22:57:21 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 3 Sep 2012 22:57:21 -0400    

Click here for diff

  
  

Use correct path separator for Windows builtin commands.

  
commit   : d10ddf4d510a5e366775f9a6bb20d0104ff1bcfd    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 3 Sep 2012 18:11:17 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 3 Sep 2012 18:11:17 -0400    

Click here for diff

  
pg_upgrade produces a platform-specific script to remove the old  
directory, but on Windows it has not been making sure that the  
paths it writes as arguments for rmdir and del use the backslash  
path separator, which will cause these scripts to fail.  
  
The fix is backpatched to Release 9.0.  
  

Make configure probe for mbstowcs_l as well as wcstombs_l.

  
commit   : 97395185b85b786523ee41225b53bd84c98d34f4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 Aug 2012 14:18:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 Aug 2012 14:18:08 -0400    

Click here for diff

  
We previously supposed that any given platform would supply both or neither  
of these functions, so that one configure test would be sufficient.  It now  
appears that at least on AIX this is not the case ... which is likely an  
AIX bug, but nonetheless we need to cope with it.  So use separate tests.  
Per bug #6758; thanks to Andrew Hastie for doing the followup testing  
needed to confirm what was happening.  
  
Backpatch to 9.1, where we began using these functions.  
  

Back-patch recent fixes for gistchoose and gistRelocateBuildBuffersOnSplit.

  
commit   : 6707dd48cdfcc95934a89df5ad4c4c2ecf0e5225    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 30 Aug 2012 23:47:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 30 Aug 2012 23:47:54 -0400    

Click here for diff

  
This back-ports commits c8ba697a4bdb934f0c51424c654e8db6133ea255 and  
e5db11c5582b469c04a11f217a0f32c827da5dd7, which fix one definite and one  
speculative bug in gistchoose, and make the code a lot more intelligible as  
well.  In 9.2 only, this also affects the largely-copied-and-pasted logic  
in gistRelocateBuildBuffersOnSplit.  
  
The impact of the bugs was that the functions might make poor decisions  
as to which index tree branch to push a new entry down into, resulting in  
GiST index bloat and poor performance.  The fixes rectify these decisions  
for future insertions, but a REINDEX would be needed to clean up any  
existing index bloat.  
  
Alexander Korotkov, Robert Haas, Tom Lane  
  

Document how to prevent PostgreSQL itself from exhausting memory.

  
commit   : f6956eb74edcdf21339f9d200ef63c4015a5f4cb    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 30 Aug 2012 14:14:22 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 30 Aug 2012 14:14:22 -0400    

Click here for diff

  
The existing documentation in Linux Memory Overcommit seemed to  
assume that PostgreSQL itself could never be the problem, or at  
least it didn't tell you what to do about it.  
  
Per discussion with Craig Ringer and Kevin Grittner.  
  

Add missing period to detail message.

  
commit   : 657face6fea6e8e29944b839c4e5ceb6c63e251e    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 30 Aug 2012 13:26:45 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 30 Aug 2012 13:26:45 -0400    

Click here for diff

  
Per note from Peter Eisentraut.  
  

Back-patch fixes for some issues in our Windows socket code into 9.1.

  
commit   : ed597d0c322dd42c362701125d4ff55eb7b675f5    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 27 Aug 2012 15:00:08 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 27 Aug 2012 15:00:08 -0400    

Click here for diff

  
This is a backport of commit b85427f2276d02756b558c0024949305ea65aca5.  
Per discussion of bug #4958.  Some of these fixes probably need to be  
back-patched further, but I'm just doing this much for now.  
  

Fix issues with checks for unsupported transaction states in Hot Standby.

  
commit   : 180ce0af338f56a6e204666b56ffedba31e60dac    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 24 Aug 2012 13:09:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 24 Aug 2012 13:09:17 -0400    

Click here for diff

  
The GUC check hooks for transaction_read_only and transaction_isolation  
tried to check RecoveryInProgress(), so as to disallow setting read/write  
mode or serializable isolation level (respectively) in hot standby  
sessions.  However, GUC check hooks can be called in many situations where  
we're not connected to shared memory at all, resulting in a crash in  
RecoveryInProgress().  Among other cases, this results in EXEC_BACKEND  
builds crashing during child process start if default_transaction_isolation  
is serializable, as reported by Heikki Linnakangas.  Protect those calls  
by silently allowing any setting when not inside a transaction; which is  
okay anyway since these GUCs are always reset at start of transaction.  
  
Also, add a check to GetSerializableTransactionSnapshot() to complain  
if we are in hot standby.  We need that check despite the one in  
check_XactIsoLevel() because default_transaction_isolation could be  
serializable.  We don't want to complain any sooner than this in such  
cases, since that would prevent running transactions at all in such a  
state; but a transaction can be run, if SET TRANSACTION ISOLATION is done  
before setting a snapshot.  Per report some months ago from Robert Haas.  
  
Back-patch to 9.1, since these problems were introduced by the SSI patch.  
  
Kevin Grittner and Tom Lane, with ideas from Heikki Linnakangas  
  

Fix cascading privilege revoke to notice when privileges are still held.

  
commit   : ff122d3268d55ace4a2ebf5f4ee1528e8a80fa98    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 23 Aug 2012 17:25:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 23 Aug 2012 17:25:23 -0400    

Click here for diff

  
If we revoke a grant option from some role X, but X still holds the option  
via another grant, we should not recursively revoke the privilege from  
role(s) Y that X had granted it to.  This was supposedly fixed as one  
aspect of commit 4b2dafcc0b1a579ef5daaa2728223006d1ff98e9, but I must not  
have tested it, because in fact that code never worked: it forgot to shift  
the grant-option bits back over when masking the bits being revoked.  
  
Per bug #6728 from Daniel German.  Back-patch to all active branches,  
since this has been wrong since 8.0.  
  

Fix bugs in contrib/pg_trgm’s LIKE pattern analysis code.

  
commit   : 874d97c2a8211cf7daaa70ee531037e69a18f4ba    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Aug 2012 13:25:03 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Aug 2012 13:25:03 -0400    

Click here for diff

  
Extraction of trigrams did not process LIKE escape sequences properly,  
leading to possible misidentification of trigrams near escapes, resulting  
in incorrect index search results.  
  
Fujii Masao  
  

Fix rescan logic in nodeCtescan.

  
commit   : 7665e82b6a6008d2df5fa67ab80d981de8b9c738    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 15 Aug 2012 19:01:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 15 Aug 2012 19:01:29 -0400    

Click here for diff

  
The previous coding essentially assumed that nodes would be rescanned in  
the same order they were initialized in; or at least that the "leader" of  
a group of CTEscans would be rescanned before any others were required to  
execute.  Unfortunately, that isn't even a little bit true.  It's possible  
to devise queries in which the leader isn't rescanned until other CTEscans  
on the same CTE have run to completion, or even in which the leader never  
gets a rescan call at all.  
  
The fix makes the leader specially responsible only for initial creation  
and final destruction of the tuplestore; rescan resets are now a  
symmetrically shared responsibility.  This means that we might reset the  
tuplestore multiple times when restarting a plan subtree containing  
multiple CTEscans; but resetting an already-empty tuplestore is cheap  
enough that that doesn't seem like a problem.  
  
Per report from Adam Mackler; the new regression test cases are based on  
his example query.  
  
Back-patch to 8.4 where CTE scans were introduced.  
  

Disallow extensions from owning the schema they are assigned to.

  
commit   : 9e035184b0fc807297dee5e2d0a219fee21fd08a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 15 Aug 2012 11:27:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 15 Aug 2012 11:27:06 -0400    

Click here for diff

  
This situation creates a dependency loop that confuses pg_dump and probably  
other things.  Moreover, since the mental model is that the extension  
"contains" schemas it owns, but "is contained in" its extschema (even  
though neither is strictly true), having both true at once is confusing for  
people too.  So prevent the situation from being set up.  
  
Reported and patched by Thom Brown.  Back-patch to 9.1 where extensions  
were added.