From: | Bill MacArthur <webmaster(at)dhs-club(dot)com> |
---|---|
To: | pgsql-admin(at)postgresql(dot)org |
Subject: | identify referential integrity triggers unassociated with foreign key constraints |
Date: | 2009-12-16 17:45:39 |
Message-ID: | 4B291CC3.7080903@dhs-club.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
Hello,
We started using Postgres back around 7.1. We've done dump and reloads to get us up to where we are now at 8.1.
Over time it would seem that the guts of foreign key constraints have changed, for the better. Soon we want to move to the latest version, but in the process, I would like to update all the old style "foreign keys" to the newest. By old style, I mean we have RI triggers on various tables like "RI_ConstraintTrigger_3495148". In pgadmin, these do not show up as triggers, neither do they show up as foreign keys as some of the system table relationships that exist now for identifying these sort of things did not exist when these "foreign keys" were first setup. (These constraints still work, you just can't tell they are they using pgadmin) Using \d tablename shows them in a list of triggers but not as Foreign-key constraints.
Occasionally I have taken to dropping some of these triggers and mucking with the system tables like pg_trigger and so forth, but those experiences are horrid. Things have never been hosed, but I know there has to be a better way.
What I would like to do is to identify these almost invisible "foreign key" triggers so that they can be dropped sanely and then create new, named constraints can be identified using ordinary tools. Is this possible?
Many thanks,
Bill MacArthur
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-12-16 18:45:42 | Re: identify referential integrity triggers unassociated with foreign key constraints |
Previous Message | Tom Lane | 2009-12-16 16:35:53 | Re: [ADMIN] recovery is stuck when children are not processing SIGQUIT from previous crash |