Thread: tuple descriptors?
Can anyone tell me how to get a tuple's TupleDesc if all that is known is the tid? Or is there an easy way to step through a tuple, retrieving the data and data type from each field?
Thanks,
Nate Sommer
"Nate Sommer" <sommena@earlham.edu> writes:
> Can anyone tell me how to get a tuple's TupleDesc if all that is known is t=
> he tid? Or is there an easy way to step through a tuple, retrieving the da=
> ta and data type from each field?
Tupledescs are generally associated with tables (relations) more easily
than with specific tuples. What exactly is your context here?
regards, tom lane
> > Can anyone tell me how to get a tuple's TupleDesc if all that is known is t= > > he tid? Or is there an easy way to step through a tuple, retrieving the da= > > ta and data type from each field? > > Tupledescs are generally associated with tables (relations) more easily > than with specific tuples. What exactly is your context here? > > regards, tom lane I'm a student taking a database systems course, and as a project option I chose to work on one of PostgreSQL's todo list items, namely "auto-delete large objects when referencing row is deleted." The main point of the project is to become more comfortable tackling large amounts of code. Working through the PostgreSQL code has been very interesting, and thus far I've worked independently, but now I'm getting a little overwhelmed. 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. I thought using TupleDescs would be helpful, but I guess my understanding of them is off. Nate Sommer
"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
"Nate Sommer" <sommena@earlham.edu> writes: > I'm a student taking a database systems course, and as a project option I > chose to work on one of PostgreSQL's todo list items, namely "auto-delete > large objects when referencing row is deleted." The main point of the > project is to become more comfortable tackling large amounts of code. BTW, I went to a pretty outstanding tutorial on just that topic this past summer at OSCON: Glenn Vanderburg on "Using the Source: Software Archaeology for Users of Open Source Software" (http://conferences.oreillynet.com/cs/os2002/view/e_sess/2869) which could be described in two seconds as "don't be afraid to get your hands dirty", and in full length as how to be effective while doing so. The pikers at O'Reilly seem not to have made Glenn's slides available on-line (isn't this a direct violation of their speakers' agreement? Mine are there...) but I'm sure Glenn would be pleased to send 'em to you on request. regards, tom lane
At 01:56 AM 10/12/2002 -0500, Tom Lane wrote: > but I'm sure Glenn would be pleased to send 'em to >you on request. Do you have an email address - the O'Reilly site also seems not to have one... ---------------------------------------------------------------- Philip Warner | __---_____ Albatross Consulting Pty. Ltd. |----/ - \ (A.B.N. 75 008 659 498) | /(@) ______---_ Tel: (+61) 0500 83 82 81 | _________ \ Fax: (+61) 03 5330 3172 | ___________ | Http://www.rhyme.com.au | / \| | --________-- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
At 01:56 AM 10/12/2002 -0500, Tom Lane wrote:
> but I'm sure Glenn would be pleased to send 'em to
>you on request.
I've found a link:
http://www.delphis.com/java/java.html
----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 03 5330 3172 | ___________ |
Http://www.rhyme.com.au | / \| | --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/
Philip Warner <pjw@rhyme.com.au> writes:
> At 01:56 AM 10/12/2002 -0500, Tom Lane wrote:
>> but I'm sure Glenn would be pleased to send 'em to
>> you on request.
> Do you have an email address - the O'Reilly site also seems not to have one...
Hrm, you're right. I think there was one in the hardcopy slides, but
that's not beside me at the moment. Before we deluge Glenn with
requests, let me ask him for a URL on behalf of the group ...
regards, tom lane