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 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
