I wrote:
> Jim Nasby <Jim.Nasby@BlueTreble.com> writes:
>> On 12/1/16 1:09 PM, Tom Lane wrote:
>>> I think that the patch I wrote is good cleanup, so I'm still inclined
>>> to apply it in HEAD, but I no longer think it's fixing any case that's
>>> significant in the field. I wonder if you have a counterexample?
>> No; I'm sure I've run into this because of a temp object other than a
>> table (probably a function, though possibly something else).
> Makes sense. The fact that we protect against this for temp tables and
> views would make it all the more surprising when you get bit by some
> less-common object type.
It occurred to me that the hack installed in 08dd23cec, to not record
a pg_depend entry for a temp table, causes its own set of misbehaviors.
If you drop the extension later in the same session, the temp table isn't
automatically removed. This would cause repeated drop/create cycles to
fail, which is kind of annoying since you might well do that during
extension development. Even more annoying, if the temp table has another
sort of dependency on the extension --- say, it uses a data type defined
by the extension --- the DROP EXTENSION would fail unless you say CASCADE.
So I've pushed this patch with an addition to revert that hack. I added
a regression test case showing that such usage behaves properly now.
regards, tom lane