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

Поиск
Список
Период
Сортировка
От Zeugswetter Andreas SEV
Тема AW: AW: AW: [HACKERS] Getting OID in psql of recent insert
Дата
Msg-id 219F68D65015D011A8E000006F8590C603FDC189@sdexcsrv1.f000.d0188.sd.spardat.at
обсуждение исходный текст
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: SQL statements: begin and end
Следующее
От: Zeugswetter Andreas SEV
Дата:
Сообщение: AW: [HACKERS] Re: SQL statements: begin and end