Re: Extension tracking temp table and causing update failure

I wrote:
> But anyway, we all seem to agree that this seems like a reasonable fix,
> so I will look into making it happen.

The attached proposed patch fixes the symptom Phil reported. However,
I think we still have some work to do. I experimented with creating
temp tables within an extension upgrade script, and found two
interesting misbehaviors that the patch doesn't fix:

1. If you forget to drop the temp table before ending the script,
then when the session ends and the temp table is forcibly dropped,
the whole extension goes away (following the rule that a forced drop
of an extension member makes the whole extension go away). This is
mildly annoying, but since not dropping the temp table is a clear bug
in an extension script, I think we can live with it.

2. #1 applies only in the typical case where the backend's temp table
schema already exists. Otherwise, when we create the pg_temp_N schema
it gets listed as one of the extension's objects. Then, when you exit
the session, this happens (behind the scenes; it's logged in the
postmaster log but not shown to the client):

FATAL: cannot drop schema pg_temp_2 because extension myext requires it
HINT: You can drop extension myext instead.

This is really bad: any temp tables created in this session won't be
cleaned out. And the same for any temp tables created in future
sessions using the same backend ID slot, since they'll get the identical
error on exit. Even worse, if you decide to drop the extension, you
might be taking out temp tables that belong to some active session other
than your own. Given those hazards and the fact that there's no
reasonable way for an extension script to avoid the risk, I think this
one is a must-fix.

I don't see any easy way around this one other than kluging temp-schema
creation to not link the temp schema to the active extension. Which is
exactly what I'd not wanted to do in ATRewriteTable. The one bright spot
about it is that temp-table schemas are inherently a special case
because of their weird creation process, so we could have some comfort
that there are probably not other similar bugs lurking.

Thoughts, better ideas?

regards, tom lane