"Nate Sommer" <[EMAIL PROTECTED]> writes: >> Tupledescs are generally associated with tables (relations) more easily >> than with specific tuples. What exactly is your context here?
> What I'd like to do is add some code to the heap_delete function that > checks the tuple being deleted for oids, compares those oids to the > loids in the pg_largeobject relation, and deletes rows accordingly. Ah. Well, heap_delete has trivial access to the appropriate tupledesc: relation->rd_att (or more cleanly RelationGetDescr(relation)) gives it to you. Not sure how large a can of worms you wanted to open here, but some creepy-crawlies I can finger offhand include: * don't forget heap_update's obsoleted tuple (but only when the replacement tuple contains a different LO oid). * [ extra credit ] don't forget heap_truncate. (If you can figure out how to do this bit without sacrificing the fundamental performance advantage of heap_truncate, then you're wasting your time dealing with us mere mortals...) * scanning pg_largeobject anytime someone wants to delete a tuple that includes an OID will be a serious performance hit, especially for updates on system catalogs --- it could even open the potential for deadlocks. Not to mention the obvious infinite-recursion problem: pg_largeobject itself has an OID column. Possibly you could finesse most of these issues by only doing the special processing for "lo" columns not "oid" columns, but that seems like a cheat. Is there a better way? * OIDs are not guaranteed unique across different system catalogs. Maybe there isn't a better way --- certainly deleting LO 42 because someone deleted pg_proc 42 wouldn't be happy-making. Within the catalogs we take care to know from context which catalog an OID must refer to, but a trigger that works on "any OID column" is at risk. You've done pretty well already to identify heap_delete as a plausible place to hack this, though. Soldier on ... regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])