Tom Lane writes:
> Actually, after I got done hacking the temp-schema case, I realized that
> preventing temp tables from becoming extension members isn't so ugly as
> I first thought; in fact, it's pretty much a one-liner, and much cleaner
> than hacking ON COMMIT DROP. PFA a patch that fixes bo
I wrote:
> Dimitri Fontaine writes:
>> 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
> l
Dimitri Fontaine writes:
> Tom Lane 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
Tom Lane 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
> m
Phil Sorber writes:
> On Wed, Mar 7, 2012 at 1:46 PM, Tom Lane wrote:
>> 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 extensi
On Wed, Mar 7, 2012 at 1:46 PM, Tom Lane wrote:
> 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
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 upg
Dimitri Fontaine writes:
> Tom Lane writes:
>> It would also have the effect that explicit DROPs of member objects in
>> extension scripts could be done without an explicit ALTER EXTENSION DROP
>> first. I think we'd originally decided that requiring the ALTER was a
>> good safety feature, but i
Tom Lane writes:
> However, recordDependencyOnCurrentExtension doesn't know that the table
> is meant to be transient and links it to the current extension; so when
> the table gets dropped a bit later, the dependency code complains.
>
> [...]
>
> Instead, I'm tempted to propose that dependency.c
On Tue, Mar 6, 2012 at 5:10 PM, Tom Lane wrote:
> Instead, I'm tempted to propose that dependency.c explicitly allow drops
> of objects that belong to the current extension, when an extension is
> being created or updated. (That is, if we come across a dependency
> reference to the active extensi
Phil Sorber writes:
> Running Postgres 9.1.3. As far as I can tell, when you do an 'alter
> table' and add a new column with a new default value a temp table is
> created and tracked by the extension as a new object, but when the
> 'alter table' statement tries to drop the temp table at the end, t
Running Postgres 9.1.3. As far as I can tell, when you do an 'alter
table' and add a new column with a new default value a temp table is
created and tracked by the extension as a new object, but when the
'alter table' statement tries to drop the temp table at the end, the
extension complains. I rec
12 matches
Mail list logo
