| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Jeff Frost <jeff(at)frostconsultingllc(dot)com> |
| Cc: | pgsql-sql(at)postgresql(dot)org |
| Subject: | Re: update before drop causes OID problems in transaction? |
| Date: | 2006-03-18 06:55:05 |
| Message-ID: | 13832.1142664905@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-sql |
Jeff Frost <jeff(at)frostconsultingllc(dot)com> writes:
> On Sat, 18 Mar 2006, Tom Lane wrote:
>> No, I think it's that you've got a plpgsql trigger function that
>> contains queries referring to credit_card_audit. Dropping and
>> recreating that table invalidates plpgsql's cached plans for those
>> queries.
> Is that the case whether the triggers are executed or not?
If the trigger function hasn't ever been executed in the current
session, it wouldn't have a cached plan ... but I suspect you meant
"if it hasn't been executed in the current transaction", and that
doesn't help.
> However, we drop that trigger before
> dropping credit_card_audit, so I'd think that would be ok.
IIRC you'd have to drop the underlying plpgsql function, not only
the trigger object that connects the function to a table. We cache
stuff with respect to the function.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Frost | 2006-03-18 07:11:33 | Re: update before drop causes OID problems in transaction? |
| Previous Message | Jeff Frost | 2006-03-18 06:48:57 | Re: update before drop causes OID problems in transaction? |