Dave Trombley <dtrom@bumba.net> writes:
> There is a particular feature I find myself wanting: Given a
> table row, I'd like a handle to that row in storage so that I may access
> it again quickly (ie. without the overhead of a SELECT).
There isn't any such thing as a "handle to that row in storage",
primarily because there's no guarantee that the row is in memory at
all. You could, however, use the row's ctid (physical location) to
access it quickly.
select ctid, ... from table where <conditions>;
...
select ... from table where ctid = 'value';
I'd only recommend that you do this within a transaction block, so that
you can be certain that the row doesn't get deleted or updated between
the two selects. Otherwise there's the possibility of retrieving no
row, or even the wrong row at the second select.
> Also, could someone explain the following (possibly related)
> error?
The rowtype-as-column functionality doesn't work; I'm not certain that
it ever has worked, at least not in the way you expect. AFAICT, the
original Berkeley implementation involved expecting to find the OID of
a *function*, not a row, in the stored column value --- this function
would be executed to get the row(s) represented. This might still work
if you cared to set it up, but I wouldn't be surprised to find it
suffering from bit rot.
regards, tom lane
