On Fri, March 9, 2007 02:27, Jim Stewart wrote: > My PostgreSQL ignorance came into play here. I didn't realize that OID > was not the same as "last inserted ID".
But it is! The problem is that what we humans may happen to think of as the row's "id" is nothing special to the DBMS. You could have any number of identifier columns, if you wanted. Or unique columns that aren't really identifiers. That first one may sound improbable but I'm sure there are situations where it makes perfect sense, such as when merging companies that assign different identifiers to the same things, or migrating to a different identification scheme. And unique rows may also reflect, say, resource allocation. > I got the ID I wanted by using > currval() on the sequence. I'm hoping this is reliable if called inside > the > same transaction as the insert. Googling around seems to indicate that > currval() is the right way to get the ID. Personally I'm not sure that that's reliable--make sure you understand the transactional behaviour of that function! It could have been designed either way. Imagine some other transaction comes along and inserts a new row before you can query currval(): if currval() is safe for your case it won't reflect that unrelated new row--but applications that assume they can use "currval()+1" will have a problem. Or the currval() that you see may be incremented as that unrelated row comes in. Jeroen _______________________________________________ Libpqxx-general mailing list Libpqxx-general@gborg.postgresql.org http://gborg.postgresql.org/mailman/listinfo/libpqxx-general
