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: | 200512010901.05688.uwe@oss4u.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-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;
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-12-01 17:11:43 | Re: fatal error in pg.log |
Previous Message | Medora Schauer | 2005-12-01 16:54:41 | Re: fatal error in pg.log |
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Page | 2005-12-01 17:10:14 | Re: [HACKERS] Upcoming PG re-releases |
Previous Message | Marc G. Fournier | 2005-12-01 17:00:59 | Re: [HACKERS] Upcoming PG re-releases |