Skip site navigation (1) Skip section navigation (2)

8.1, OID's and plpgsql

From: "Uwe C(dot) Schroeder" <uwe(at)oss4u(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: 8.1, OID's and plpgsql
Date: 2005-12-01 17:01:05
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-generalpgsql-hackers
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;
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 ?



pgsql-hackers by date

Next:From: Dave PageDate: 2005-12-01 17:10:14
Subject: Re: [HACKERS] Upcoming PG re-releases
Previous:From: Marc G. FournierDate: 2005-12-01 17:00:59
Subject: Re: [HACKERS] Upcoming PG re-releases

pgsql-general by date

Next:From: Tom LaneDate: 2005-12-01 17:11:43
Subject: Re: fatal error in pg.log
Previous:From: Medora SchauerDate: 2005-12-01 16:54:41
Subject: Re: fatal error in pg.log

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group