Re: Error from trigger

On Thursday 08 December 2005 00:23, Tom Lane wrote:
>Is there a reason you don't just mark the FK reference as ON DELETE
>CASCADE, rather than using a handwritten trigger?

I could have done that, of course. I'm still a little shaky on "best 
practice" with these things. Besides, I haven't found out yet how to 
alter the table to make the reference cascading. And I wanted to 
experiment with simple triggers.

>Offhand this looks like you might have dropped and recreated the
>event_citations table?  If so it's just the known problem that
>plpgsql caches plans and doesn't throw them away when the referenced
>objects change.

Right on target. Thank you. A few days ago, as I have already related on 
this list, I did the following to fix a bad design with inherited 
tables:

pgslekt=> create table event_cits (
pgslekt(> event_fk integer references events (event_id),
pgslekt(> source_fk integer references sources (source_id),
pgslekt(> PRIMARY KEY (event_fk, source_fk)
pgslekt(> );
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index 
"event_cits_pkey" for table "event_cits"
CREATE TABLE
pgslekt=> insert into event_cits (select event_fk, source_fk from 
event_citations);
INSERT 0 29139
pgslekt=> drop table event_citations cascade;
NOTICE:  drop cascades to rule _RETURN on view event_notes
NOTICE:  drop cascades to view event_notes
DROP TABLE
pgslekt=> drop table citations;
DROP TABLE
pgslekt=> alter table event_cits rename to event_citations;
ALTER TABLE
pgslekt=> \i views_and_functions.sql

I've run a VACUUM FULL ANALYZE, but that doesn't seem to cure the 
situation. Is there a way to fix it, short of a full dump, drop, and  
reload?
-- 
Leif Biberg Kristensen | Registered Linux User #338009
http://solumslekt.org/ | Cruising with Gentoo/KDE