Re: tuple descriptors?

"Nate Sommer" <sommena(at)earlham(dot)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 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