From: | "John Hansen" <john(at)geeknet(dot)com(dot)au> |
---|---|
To: | "Alvaro Herrera" <alvherre(at)dcc(dot)uchile(dot)cl> |
Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Michael Fuhr" <mike(at)fuhr(dot)org>, "Mitch Pirtle" <mitch(dot)pirtle(at)gmail(dot)com>, "Tatsuo Ishii" <t-ishii(at)sra(dot)co(dot)jp>, <pgsql-hackers(at)postgresql(dot)org>, <operationsengineer1(at)yahoo(dot)com>, <pgsql-novice(at)postgresql(dot)org> |
Subject: | Re: [NOVICE] Last ID Problem |
Date: | 2005-02-01 14:48:49 |
Message-ID: | 5066E5A966339E42AA04BA10BA706AE56245@rodrick.geeknet.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-novice |
> > Since OID's are now deprecated, and will eventually disappear,
> > wouldn't it be a good idea, to have INSERT and UPDATE
> return a copy of
> > the tuple that was inserted/updated?
>
> How about the TID?
Yea, that'd work. As long as you can get an arbitrary column back out, 'as it was at the time it was committed'.
Since not everything runs in a transaction,. And someone might have modified the row by the time you get to fetching it back out....
Or in terms of tuples,. No longer exist, if vacuum full have run...
... JOhn
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Buttafuoco | 2005-02-01 15:12:27 | float4 regression test failed on linux parisc |
Previous Message | Alvaro Herrera | 2005-02-01 14:24:38 | Re: [NOVICE] Last ID Problem |
From | Date | Subject | |
---|---|---|---|
Next Message | James DeMond | 2005-02-01 15:06:30 | Re: Arrays of user-defined data types in other user-defined |
Previous Message | Alvaro Herrera | 2005-02-01 14:24:38 | Re: [NOVICE] Last ID Problem |