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