Re: tuple descriptors?

"Nate Sommer"  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