Re: CURRENT OF cursor without OIDs
| От | Ian Lance Taylor |
|---|---|
| Тема | Re: CURRENT OF cursor without OIDs |
| Дата | |
| Msg-id | si3d73idk8.fsf@daffy.airs.com обсуждение исходный текст |
| Ответ на | Re: CURRENT OF cursor without OIDs (Hiroshi Inoue <Inoue@tpf.co.jp>) |
| Список | pgsql-hackers |
Hiroshi Inoue <Inoue@tpf.co.jp> writes: > > Ian Lance Taylor <ian@airs.com> writes: > > > Anyhow, I see that there is a move afoot to eliminate mandatory OIDs. > > > My question now is: if there is no OID, is there any comparable way to > > > implement CURRENT OF cursor? Basically what is needed is some way to > > > identify a particular row between a SELECT and an UPDATE. > > > > I'd look at using TID. Seems like that is more efficient anyway (no > > index needed). Hiroshi has opined that TID is not sufficient for ODBC > > cursors, but it seems to me that it is sufficient for SQL cursors. > > > > Yes TID is available and I introduced Tid Scan in order > to support this kind of implementation. However there > are some notices. > 1) Is *FOR UPDATE* cursor allowed in PL/pgSQL ? > (It doesn't seem easy for me). No, it is not supported right now. Conceptually, however, PL/pgSQL could pull out the FOR UPDATE clause and turn it into an explicit LOCK statement. The TID hack will only work for a cursor which selects from a single table, so this is the only case for which turning FOR UPDATE into LOCK has to work. Admittedly, this is not the same as SELECT FOR UPDATE, because I think PL/pgSQL would have to lock the table in ROW EXCLUSIVE mode. But I think it would work, albeit not with maximal efficiency. Ian
В списке pgsql-hackers по дате отправления: