| From: | Mike Nolan <nolan(at)gw(dot)tssi(dot)com> |
|---|---|
| To: | doug(at)mcnaught(dot)org (Doug McNaught) |
| Cc: | tgl(at)sss(dot)pgh(dot)pa(dot)us (Tom Lane), kleptog(at)svana(dot)org, db(at)zigo(dot)dhs(dot)org (Dennis Bjorklund), spinel(at)noos(dot)fr (Stephane Pinel), pgsql-general(at)postgresql(dot)org |
| Subject: | Re: GetLastInsertID ? |
| Date: | 2004-01-04 23:41:37 |
| Message-ID: | 200401042341.i04NfcP3002199@gw.tssi.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
> How, exactly, would this happen? Is this worry based on an analysis
> of the source code, or just speculation?
No, I haven't examined that part of the PG source code. However, I've
beta tested software for several decades, and I'm wary of any promises
like those proferred for nextval/currval. Besides, Tom has already pointed
out one flaw in it, involving persistent connections. (And I could
easily see how in a large project team the person writing the nextval/currval
code might not know whether or not the connection was persistent.)
Could there be others? I'm not willing to bet my application's consistency
and data integrity against it. Assuming that there aren't risks or
problems with accepted techniques is how most large software projects
create flaws.
If hackers have done anything positive for software development, it is
that they have demonstrated that nearly all memory-based schemes can
have overflow problems.
--
Mike Nolan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Martijn van Oosterhout | 2004-01-04 23:55:20 | Re: GetLastInsertID ? |
| Previous Message | Doug McNaught | 2004-01-04 23:04:30 | Re: GetLastInsertID ? |