AW: AW: AW: [HACKERS] Getting OID in psql of recent insert - Mailing list pgsql-hackers

From Zeugswetter Andreas SEV
Subject AW: AW: AW: [HACKERS] Getting OID in psql of recent insert
Date
Msg-id 219F68D65015D011A8E000006F8590C603FDC189@sdexcsrv1.f000.d0188.sd.spardat.at
Whole thread Raw
List pgsql-hackers
> > Ok, the fact, that the row changed is known, because we can 
> check the 
> > snapshot. We also know, that the new row must be near the 
> physical end 
> > of the table, so maybe we could do a backward scan ?
> > Maybe we could also simply bail out, like Oracle with a 
> "snapshot too old" 
> > error message  ?
> > (I know that this is not the same situation as the stated 
> Oracle error)
> 
> That is too strange.  If the tuple is superceeded, not sure how to
> handle that.  My guess is that we just let them access it.  How do we
> know if it is still a valid tuple in their own transaction?  
> I am unsure
> of this, though.  Maybe there is a way to know.

I think we do know, since when doing any seq scan we also have to know.

> > Do we use the sql syntax 'where rowid = :xxx' for it, 
> > or do we say 'where ctid = :xxx'.
> > I would like the rowid naming, because Informix, Oracle 
> (and DB/2 ?) use it.
> 
> Is Informix rowid an actual physical row location.  

Yes, it consists of page number and slot id, and is one integer.

Basically the same thing in Oracle.
How the value is printed is imho irrelevant, since it is not for the eye.

> If so, it would be
> nice to auto-rename the column references to ctid on input.  
> Good idea.

Andreas


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: SQL statements: begin and end
Next
From: Zeugswetter Andreas SEV
Date:
Subject: AW: [HACKERS] Re: SQL statements: begin and end