On 12/1/05, Uwe C. Schroeder <uwe@xxxxxxxxx> wrote: > > Hi everyone, > > in 8.1 by default tables have no OID's anymore. Since OID's are 4 byte it's > probably a good idea to discourage the use of them (they produced a lot of > trouble in the past anyways, particularly with backup/restores etc) > > Now there's the issue with stored procs. A usual construct would be to > ... > ... > INSERT xxxxxx; > GET DIAGNOSTICS lastoid=RESULT_OID; > SELECT .... oid=lastoid; > .... > .... > > Is there anything one could sanely replace this construct with? > I personally don't think that using the full primary key is really a good > option. Say you have a 3 column primary key - one being a "serial", the > others for example being timestamps, one of them generated with "default" > options. In order to retrieve the record I just inserted (where I don't know > the "serial" value or the timestamp) I'd have to > > 1) store the "nextval" of the sequence into a variable > 2) generate the timestamp and store it to a variable > 3) generate the full insert statement and retain the other values of the > primary key > 4) issue a select to get the record. > > Personally I think this adds unneccessary overhead. IMHO this diminishes the > use of defaults and sequences unless there is some easier way to retrieve the > last record. I must be missing something here - am I ? > > UC > If you are using a SERIAL in your PK, why you need the other two fields? The serial will undoubtly identify a record? you just retrieve the current value you inserted with currval -- Atentamente, Jaime Casanova (DBA: DataBase Aniquilator ;)
