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 по дате отправления:

Предыдущее
От: Hiroshi Inoue
Дата:
Сообщение: Re: CURRENT OF cursor without OIDs
Следующее
От: Hiroshi Inoue
Дата:
Сообщение: Re: CURRENT OF cursor without OIDs