Re: OIDs as object handles?
От | Tom Lane |
---|---|
Тема | Re: OIDs as object handles? |
Дата | |
Msg-id | 340.1009733349@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | OIDs as object handles? (Dave Trombley <dtrom@bumba.net>) |
Список | pgsql-general |
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
В списке pgsql-general по дате отправления: