From: | Forest Wilkinson <fspam(at)home(dot)com> |
---|---|
To: | pgsql-sql(at)postgresql(dot)org |
Subject: | unreferenced primary keys: garbage collection |
Date: | 2001-01-20 04:54:21 |
Message-ID: | 4l5i6tcr56fkb8hob8a3bas3ce0qq53d6l@4ax.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
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.
I suppose I could write procedural code in my client application, to check
for abandonment when a reference is removed, but that would require
examining each of the five referencing tables. I consider this a messy
option, and I expect it would be rather inefficient.
I thought of attempting to delete the address record any time a reference
to it is removed, and relying on foreign key constraints to prevent the
deletion if it is referenced elsewhere. However, I believe postgres will
force the entire transaction block to be rolled back in such cases, thus
nullifying all the other work done in the transaction. This is clearly
undesirable.
Isn't there some way to tell postgres *not* to roll back my transaction if
a particular DELETE fails due to referential integrity? Are there any
other options that might help me?
Regards,
Forest Wilkinson
From | Date | Subject | |
---|---|---|---|
Next Message | Ian Harding | 2001-01-20 05:04:12 | Re: pl/pgsql Limits |
Previous Message | Ian Harding | 2001-01-20 04:31:09 | Re: pl/pgsql Limits |