"Nate Sommer" <sommena@earlham.edu> 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
fundamentalperformance 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
obviousinfinite-recursion problem: pg_largeobject itself has an OID column. Possibly you could finesse most of these
issuesby only doing the special processing for "lo" columns not "oid" columns, but that seems like a cheat. Is there a
betterway?
* OIDs are not guaranteed unique across different system catalogs. Maybe there isn't a better way --- certainly
deletingLO 42 because someone deleted pg_proc 42 wouldn't be happy-making. Within the catalogs we take care to know
fromcontext 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