select max(some_value)+1 from foo
DOES NOT WORK. As Jeff says, sequences were invented by vendors for a reason.
The *only* way to make that statement work in a concurrent environment is to do a full table lock or the insert-until-it doesn't fail approach. Both are ugly.
Even if concurrency weren't a problem, as the table grows, the full table scan required by the max() function would become an issue, particularly in PostgreSQL (in Oracle it's not so bad because the aggregate can scan the index rather than the full table, but PG's multiversioning storage system makes that optimization impossible).
I personally don't see exposing object_ids in the general case as being that big a deal. Migration of data to a non-OACS system is going to be a PITA and this would be just one of many, many things to tackle.
On the other hand I agree that having nice bug numbers is useful. People communicate about bugs in e-mail and the like, and being able to say "Check out bugs 23 through 25 in OpenACS" is more convenient than saying "Check bugs 75763, 77321, and 78212".
Here's one idea: create a sequence for each instance of the bug tracker that's mounted, using the package_id as part of the sequence name. Create it in the post instantiate callback proc. It would then be easy enough to use the dynamic name in your queries that grab the next available number.
Something like:
select nextval('bt_[ad_conn package_id]_seq');
This works beautifully in a high concurrency environment. It doesn't slow down as your table of bugs grows. You can do double-click detection using the object_id (use ad_form's "key" psuedo-datatype, which also signs and verifies the object_id which is generated) so you don't have to grab the nextval until you're actually inserting the new bug. And if there's a failure for some reason leaving a "hole" in the sequence wouldn't be that big a deal, because such failure should be very rare if everything's put together correctly.
