tuple descriptors?

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

"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