Bug 225221 - a primary key for longdescs

[Zak Greant]

Greetings All,

I have been lurking, watching to see what happens with the Sxip stuff. 
However, since I used to work for MySQL, I could not resist this 
question.

On Oct 14, 2004, at 15:37, David Miller wrote:
> Christopher Hicks wrote:
>> On Mon, 11 Oct 2004, Joel Peshkin wrote:
>>> Also, nobody is obstructing that bug, but nobody seems to have taken 
>>> on the task of making the conversion code work properly.  For 
>>> existing databases, it is probably necessary to first assign 
>>> integers to the new field in the correct order, then identify the 
>>> new field as a primary key.
>> That won't work!  How can you assign integers to something you can't 
>> uniquely refer to?  The simplest and most painless way to get past 
>> the chicken and egg problem is by having MySQL do it (as my patches 
>> have done) you end up with a primary key already filled out for you.  
>> It seems so simple yet its taken so long and folks still don't get 
>> it.  So I gripe.
>
> You missed the "in the correct order" part.  MySQL will happily assign 
> them for you, but there's no guarantee they'll wind up in the order 
> you expect them.  On the other hand, if there is such a guarantee, 
> point it out to me in the MySQL docs and I'll change my mind. :)

MySQL, in most common use cases, will generate a sequential set of 
integers. As rows are deleted, the corresponding integers will not be 
re-used. The exceptions to this are multi-column primary keys with 
auto_increment fields and some versions of MySQL > 3 years old.

Still, why rely on a feature that is only supported by one database? It 
seems better to be more independent. <shrug>

Cheers!
--zak