> That way they really can't touch the sequence; otherwise they still > could call nextval multiple times erroneously (people do that...). It > doesn't matter much to the sequence, of course... It just leaves the > ugly gaps out :P The sequence facility was NOT designed with no-gap sequencing in mind, but with good parallel performance in mind. For example you will never be able to recover a sequence value if the transaction which got it rolls back... no matter what other gimmicks you do. And you will always get gaps when you delete some rows, so there's really not much point in caring at all about the gaps. I do understand that there are applications where the operators feel more comfortable memorizing the ids they often use and typing in those directly instead of choosing from drop-downs... I've been there, seen that. I could do mostly nothing against that habit, typing is always faster than choosing from drop-downs. In those cases it makes sense to provide some special support for making the frequently used IDs small, or otherwise streamlining the GUI so that choosing is not often needed, and possibly do it by aliasing so that the aliases are not easily overlapping when mistyped... in any case, typing in IDs is always error prone even if it is faster. In the case I dealt with, there was a huge mess of mistakenly introduced IDs (coming from the inherited application where the only way to navigate was through typing in IDs), and I ended up by coding some heuristics for searching for IDs in the DB which could be a possible mistaken version of some given ID... interesting experience regarding what are the most common mistypings, but the only real conclusion was to avoid such stuff in any application I get the chance to code from scratch. So the real answer here is: you don't need IDs without gaps, and if you think you need them, use letter codes instead, and even those so chosen that mistyping won't get you to another existing code. Cheers, Csaba.
