[zeograd]

I often see code relying on the increasing property of primary key (keeping track of processed vs unprocessed by the last processed pk only).

This wrap into negative domain would wreck havoc for sure.

[CodesInChaos]

You generally can't rely on strict monotonicity of primary keys, since the order in which transactions commit isn't necessarily the order in which the ids were generated. But I have relied on primary keys being "monotonic enough" to sort output by creation time for display purposes.

[OptionOfT]

I've worked on invoicing software where we had to introduce a public, always +1 counter to ensure there are no gaps between invoices. Not +2, not +5.

That way you couldn't make them disappear.

[veyh]

Well, I'd imagine that before returning the value through their API they could just check that if the number is negative, then add 2^32 to it, which would make it look like an unsigned 32 bit integer.

[conradfr]

But isn't that exactly what they were trying to not do as their problem was the api users and not their internal use?

[layer8]

In most languages that support differently sized integer types and/or unsigned integer types, you wouldn’t have to check, but can just apply the appropriate modulo or bit operation on all values.