Martijn,

> >>Eh, also, I think that there has to be some way to get the value back to
> the
> >>client. :)
>
> >And..Ugh, just think what problems there would be in our comfortable little
> world if that >AUTOINC type were under transaction control...
> >Helen
>
> Eh, more ugh... Personally, I hate autoinc fields - but people really seem
> to use them :)
>
> And IF they get implemented, you really need to be able to get the value at
> the client.

This is absolutely required, and perhaps Jason's suggestion was directed
towards this. I could even accept the engine overwriting anything I
could have put in (so, no test for null), but it must give me back the
values.
A RETURNING clause of the INSERT statement seems to me a not too bad way
to handle this. It would be useful also to get applied defaults,
modified non key fields, etc.

After all, I think the RETURNING clause would be much more useful than
an AUTOINC type (which we, basically, already have).

WRT transaction control, of course the increment operation should be out
of transaction control (unless we figure a different way to guarantee
uniqueness and stay as cheap as generators are), and of course the
assignment of the "generated" value to the column should be, as the
whole INSERT, under transaction control.

Finally, I think all this is more suited for the ib-architect or
ib-priorities list.
Ciao
--
____
_/\/ando