Re: [HACKERS] tuple descriptors?
Philip Warner <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] tuple descriptors?
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 |/ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] tuple descriptors?
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 |/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] tuple descriptors?
"Nate Sommer" <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] tuple descriptors?
"Nate Sommer" <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] tuple descriptors?
> > 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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] tuple descriptors?
"Nate Sommer" <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
