On Sat, Mar 08, 2003 at 09:44:16PM -0800, Jonathan Leffler wrote:
> Tim Bunce wrote:
> >
> >Can you tell if the last insert generated a SERIAL or SERIAL8 id?
> >Or would the application need to give you a hint?
>
> I don't need an application hint, though I can't readily tell either.
>
> The SERIAL I can guess pretty reliably simply by looking at the field
> in the SQLCA -- if it isn't zero, chances are a serial was inserted.
So the SQLCA is cleared for each statement and only set non-zero for
an insert into a table with a SERIAL column?
> With SERIAL8, I have no information readily available.
But if the above is true, then if the application asks for
$dbh->last_insert_id and the SQLCA field is 0 then you could
reasonably assume that the SERIAL8 should be used.
[I agree that dbh is better than sth, and the DBI spec will say
that the info is potentially very short lived and should be got
immediately after the insert.]
> >>For the special case of SERIAL8, I can provide a suitable access
> >>method - probably $dbh->ix_last_serial8() via the nice new mechanism
> >>you've exposed for adding methods to the DBI. Or as an attribute such
> >>as $dbh->{ix_last_serial8} -- it's much the same.
> >
> >But that implies that the application *knows* it was a serial8.
> >I can imagine that a table might be altered from serial to serial8,
> >but you wouldn't want to have to change all the applications.
>
> Interesting observation, but existing applications can't fish 64-bit
> integer values out of 32-bit storage reliably -- so they'd have to
> change. That, in conjunction with various other observations about
> the (lack of) usage of features that are not as operational as I'd
> like tends to suggest that such features are not very widely used anyway.
Sure. Today. I'd hate you or the DBI spec to get boxed into a corner
so it's worth exploring further even if SERIAL8 support ends up
not being implemented in the short term.
Tim.
