| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "John Hansen" <john(at)geeknet(dot)com(dot)au> |
| Cc: | "Alvaro Herrera" <alvherre(at)surnet(dot)cl>, "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Neil Conway" <neilc(at)samurai(dot)com>, "Dennis Bjorklund" <db(at)zigo(dot)dhs(dot)org>, pgsql-patches(at)postgresql(dot)org |
| Subject: | Re: lastval() |
| Date: | 2005-05-12 14:28:43 |
| Message-ID: | 394.1115908123@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-patches |
"John Hansen" <john(at)geeknet(dot)com(dot)au> writes:
>> Hmm, if your app can build any of them at an arbitrary point,
>> you have a rather serious problem, I'd say. The apps I've
>> seen build either kind at each call site of such runquery().
> Actually, the app that I am referring to, does just that.
> However, in some instances, the only difference between two queries, would be the table name.
> A primary, with a serial as primary key, and a secondary without a serial.
> Inserting into the secondary, gives no sequence value, and thus currval() (or lastval()) would fail.
> I solved the error issue by hardcoding the table names available in runquery(), such that currval() is only called when the table is one of those containing a serial primary key. Not very elegant, which is why I'd like to see at least the lastval(false) method implemented.
I continue to find this argument completely unconvincing. If we provide
a function that works like that, then the result will be that whenever
you insert into the secondary table, your application will obtain and
use a completely WRONG answer --- namely the sequence value from some
other table entirely. If your code is able to not do anything wrong as
a result, it seems to me it could refrain from calling the function in
the first place.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2005-05-12 15:26:58 | Re: AllocSetReset improvement |
| Previous Message | Tom Lane | 2005-05-12 13:50:28 | Re: [HACKERS] plperl and pltcl installcheck targets |