Alvaro Herrera wrote:
> Sent: Thursday, May 12, 2005 6:36 AM
> To: John Hansen
> Cc: Bruce Momjian; Neil Conway; Dennis Bjorklund; 
> Subject: Re: [PATCHES] lastval()
> On Thu, May 12, 2005 at 04:58:54AM +1000, John Hansen wrote:
> > Alvaro Herrera wrote:
> > > Actually, having it throw an error would be helpful, because then 
> > > you can find in the application which calls should be replaced by 
> > > the generic runquery() that has to return nothing versus the one 
> > > that has to return a sequence value.  So porting is a little more 
> > > involved but more useful in the end.
> > 
> > Indeed, but my point was that often it is going in the too 
> hard basket.
> > Not that I disagree, but how do you predetermine which 
> queries would 
> > throw an error if they're built dynamically?
> 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.

> --
> Alvaro Herrera (<alvherre[a]>)
> "La fuerza no está en los medios físicos sino que reside en 
> una voluntad indomable" (Gandhi)

... John

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?


Reply via email to