AW: AW: AW: [HACKERS] Getting OID in psql of recent insert

From: Zeugswetter Andreas SEV <ZeugswetterA(at)wien(dot)spardat(dot)at>
To: "'pgsql-hackers(at)postgreSQL(dot)org'" <pgsql-hackers(at)postgreSQL(dot)org>
Subject: AW: AW: AW: [HACKERS] Getting OID in psql of recent insert
Date: 1999-11-23 19:12:49
Message-ID: 219F68D65015D011A8E000006F8590C603FDC189@sdexcsrv1.f000.d0188.sd.spardat.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Browse pgsql-hackers by date

  From Date Subject
Next Message Zeugswetter Andreas SEV 1999-11-23 19:20:32 AW: [HACKERS] Re: SQL statements: begin and end
Previous Message Bruce Momjian 1999-11-23 18:24:46 Re: [DOCS] RE: file name error (fwd)