Re: unreferenced primary keys: garbage collection

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.