From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Phil Sorber <phil(at)omniti(dot)com> |
Cc: | Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: Extension tracking temp table and causing update failure |
Date: | 2012-03-07 22:08:25 |
Message-ID: | 20361.1331158105@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Phil Sorber <phil(at)omniti(dot)com> writes:
> On Wed, Mar 7, 2012 at 1:46 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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 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.
> This seems a little bit more than mildly annoying to me.
Well, I didn't say it wasn't annoying, but it would only be catastrophic
if applied to a production database; and it's certainly the sort of
thing you'd notice while testing the extension script. Keep in mind
that those scripts run as superuser, so they can already do arbitrary
amounts of damage to your DB if inadequately tested.
If there were a reasonably non-ugly way to deal with the case I'd be
willing to put it in, but I don't see one. I think the best we can do
is document it.
The other case, which only triggers if the script is run in a previously
virgin backend ID, scares me a lot more because it's the kind of corner
case that could easily escape reasonable testing of an extension script.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-03-08 00:27:15 | Re: BUG #6480: NLS text width problem |
Previous Message | Merlin Moncure | 2012-03-07 20:49:39 | Re: [GENERAL] Altering a table with a rowtype column |