Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> 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.
> Could we force temp tables created in an extension script to be ON
> COMMIT DROP so that CurrentExtensionObject is still set and your patch
> kicks in, preventing the DROP cascading?
Huh, yeah, that might work. It's ugly but at least the ugliness is
localized; and there's no obvious reason why such a temp table ought to
survive past the end of the script.
In a quick look, we can't do it exactly like that because
CurrentExtensionObject isn't still set at transaction end; but I think
we could call PreCommit_on_commit_actions just before we clear
CurrentExtensionObject, so that the drops are done a tad early.
> We might want to protect in the same way against temp schema explicitly
> created by the extension script too (IIRC you can actually do that): it
> could be just about documentation, but if that's not too much contorting
> the code it would be better to just ERROR out, I think.
Nah, that's not a reasonable thing for an extension script to do IMO.
We are not in the business of trying to prevent superusers from thinking
of creative ways to break their database. I'll be satisfied if a
routine CREATE TEMP TABLE in an extension script is safe.
regards, tom lane