One other method is to setup up the foreign keys as ON DELETE RESTRICT,
then outside of your transaction block issue a DELETE FROM address WHERE
add_id = 1; If there are still records in the other tables referencing
this record, it will error out and nothing will happen, however if no
related records are left, the delete will succeed (you have to do it
outside of transaction, otherwise I belive it will rollback on the
error if other rows are found to be referencing the primary key)....
Michael Fork - CCNA - MCP - A+
Network Support - Toledo Internet Access - Toledo Ohio
On Tue, 23 Jan 2001, Forest Wilkinson wrote:
> Jan,
>
> Thanks for the reply, but your solution is rather unattractive to me. It
> requires that, any time a reference to an address id is changed, five
> tables be searched for the address id. This will create unwanted overhead
> every time a change is made. In order to make those searches even
> remotely fast, I'd have to add indexes to every one of those tables, which
> will mean an additional performance hit on table inserts. Moreover, if a
> new table is created that references address ids, and the maintainer at
> the time forgets to rewrite those trigger functions, the system will
> break.
>
> I'd much rather be able to simply attempt a delete of any given address,
> relying on referential integrity to prevent the delete if the address is
> still being referenced. I don't see why postgres has to treat such a
> situation as a fatal error. If postgres issued (for example) a warning
> instead of an error here, I'd be home free! Hasn't there been some talk
> on the lists about this lately?
>
> Forest
>
> Jan Wieck wrote:
> >> While this behaviour makes sense in your case, it's not
> >> subject to referential integrity constraints. You could
> >> arrange for it with custom trigger procedures, checking all
> >> the five tables on DELETE or UPDATE on one of them.
>
> Forest Wilkinson wrote:
> >> > I have a database in which five separate tables may (or may not) reference
> >> > any given row in a table of postal addresses. I am using the primary /
> >> > foreign key support in postgres 7 to represent these references.
> >> >
> >> > My problem is that, any time a reference is removed (either by deleting or
> >> > updating a row in one of the five referencing tables), no garbage
> >> > collection is being performed on the address table. That is, when the
> >> > last reference to an address record goes away, the record is not removed
> >> > from the address table. Over time, my database will fill up with
> >> > abandoned address records.
>
