alphanumerics won't solve anything here.
We are still in a 32-bit headroom. Changing the visual represenatation
from base-10 to base-64 won't make any difference.
Bloody hell, come to think of it: bigints don't fit in a 32bit space
either. Time to rethink...
Kevin Baker wrote:
>
>
>>I'm inter
Ok, let me recapitulate:
- we want to replace all auto-incremented fields with bigint fields to
hold uuids in order to accomodate N-clustered databases.
- we can't directly use those uuids as UID message attributes because
those are required to be 32bit, whereas uuids will need to be 64bit or
lon
On Thu, 2005-05-26 at 13:49 +0200, Paul J Stevens wrote:
> Ok, let me recapitulate:
>
> - we want to replace all auto-incremented fields with bigint fields to
> hold uuids in order to accomodate N-clustered databases.
> - we can't directly use those uuids as UID message attributes because
>
The following bug has been SUBMITTED.
==
http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=208
==
Reported By:gonecrazy25
Assigne
Geo Carncross wrote:
> On Thu, 2005-05-26 at 13:49 +0200, Paul J Stevens wrote:
>
>>Ok, let me recapitulate:
>>
>>- we want to replace all auto-incremented fields with bigint fields to
>>hold uuids in order to accomodate N-clustered databases.
>
>
>
>
>
>>- we can't directly use those uui
> Geo Carncross wrote:
>> On Thu, 2005-05-26 at 13:49 +0200, Paul J Stevens wrote:
>>
>>>Ok, let me recapitulate:
>>>
>>>- we want to replace all auto-incremented fields with
>>> bigint fields to
>>>hold uuids in order to accomodate N-clustered databases.
So the problem seems to be generating a se
I think an important question to ask is how many messages we really want
to be able to fit into a mailbox. IMAP's 32 bit limit, and that some
clients treat those 32 bits as signed (is this true? do we need to
worry?), indicates that there's already a limit of 2 billion messages per
mailbox.
If we'
