Neil Conway wrote:<br /><blockquote cite="mid1042241157.743.17.camel@tokyo" type="cite"><pre wrap="">On Fri,
2003-01-10at 18:17, Ashley Cambrell wrote: </pre><blockquote type="cite"><pre wrap="">The problem with getting rid of
OIDsas default is there is then no way
to get the primary key of a just inserted row with out OIDs (as far as I
know) </pre></blockquote><pre wrap="">
Use currval() on the PK sequence -- if you call it from within the query
that inserted a row, it is guaranteed to give you the last sequence
value that it generated. </pre></blockquote><br /> First problem though is that you have to know the sequence name that
isautogenerated from the serial<br /><br /> secondly, I thought that sequences worked outside of transactions..<br
/><br/> process 1<br /><br /> INSERT INTO testtable(text1) VALUES('blah1'); -- testid_seq now 1<br /><br /> process
2<br/><br /> INSERT INTO testtable(text1) VALUES('blah2'); -- testid_seq now 2<br /> SELECT currval('testid_seq'); --
returns2<br /><br /> process 1<br /> SELECT currval('testid_seq'); -- returns 2<br /><br /> ??<br /><br /><blockquote
cite="mid1042241157.743.17.camel@tokyo"type="cite"><pre wrap="">
However, I agree that one of the drawbacks of this scheme would be
breaking the OID in the status string returned by INSERT and similar
commands. Not too big a deal, IMHO (users can still get the same effect
by specifying WITH OIDS, or toggling the GUC var)... </pre></blockquote> The users who don't know any better and expect
thatpg_getlastoid should return the last oid will have trouble. There really should be alternative first, like binding
variablesand RETURNING INTO. Is it on the TODO list by any chance? <br /><blockquote
cite="mid1042241157.743.17.camel@tokyo"type="cite"><pre wrap="">
Cheers,
Neil </pre></blockquote> Ashley Cambrell<br />
