From: | Ian Lance Taylor <ian(at)airs(dot)com> |
---|---|
To: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: CURRENT OF cursor without OIDs |
Date: | 2001-08-08 00:46:15 |
Message-ID: | si3d73idk8.fsf@daffy.airs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> writes:
> > Ian Lance Taylor <ian(at)airs(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Hiroshi Inoue | 2001-08-08 01:04:10 | Re: CURRENT OF cursor without OIDs |
Previous Message | Hiroshi Inoue | 2001-08-08 00:12:15 | Re: CURRENT OF cursor without OIDs |