
> They get the location they ask for, or a failure.  Hunting around for
> the new tuple seems like a real waste, and if someone vacuums, it is
> gone, no?

It is probably worse, since they might even get the wrong row, 
but that's the same in Informix and Oracle.

In Informix:

a: selects rowid
b: updates row, row grows, does not fit in page, is relocated
c: inserts rows, pysical location of rowid is reused
a: selects row by rowid, gets differet row --> bummer

Andreas

Tue, 23 Nov 1999 20:29:11 +0100
Zeugswetter Andreas SEV <ZeugswetterA@wien.spardat.at>
AW: AW: AW: [HACKERS] Getting OID in psql of recent insert
> 
> > They get the location they ask for, or a failure.  Hunting around for
> > the new tuple seems like a real waste, and if someone vacuums, it is
> > gone, no?
> 
> It is probably worse, since they might even get the wrong row, 
> but that's the same in Informix and Oracle.
> 
> In Informix:
> 
> a: selects rowid
> b: updates row, row grows, does not fit in page, is relocated
> c: inserts rows, pysical location of rowid is reused
> a: selects row by rowid, gets differet row --> bummer
>

In my implementation,scan by old(updated) tupleid fails.
For example,

	=> create table t (dt int4);
	CREATE
	=> insert into t values (1);
	INSERT 18601 1
	=> select ctid,* from t;
	ctid |dt
	-----+--
	(0,1)| 1
	(1 row)

	=> select * from t where ctid='(0,1)';
	dt
	--
	 1
	(1 row)

	=> update t set dt=2;
	UPDATE 1
	=> select * from t where ctid='(0,1)';
	dt
	--
	(0 rows)


In order to get new tids,I provided functions currtid() and currtid2().

	=> select currtid2('t','(0,1)');
	currtid2
	--------
	(0,2)
	(1 row)

	=> select * from t where ctid='(0,2)';
	dt
	--
	 2
	(1 row)

Of cource,this function is not effective after vacuum.
If you want to detect the change by vacuum,keep oids together with tids.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp



Wed, 24 Nov 1999 16:36:02 +0900
"Hiroshi Inoue" <Inoue@tpf.co.jp>
RE: AW: AW: [HACKERS] Getting OID in psql of recent insert