Re: tuple descriptors?

"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