1. That would be true only for the automatically created primary key
fields. For all other integer fields the default for unsigned is false
- so nothing changes.
2. Yes and yes. For example, if you move to a version of Rails with
unsigned support, you could write a migration that does things like
this:
change_column :suppliers, :category_id, :integer, :unsigned => true
or
change_table :products do |t|
  t.change :id, :integer, :unsigned => true
end
3. That's correct, you can't have a signed foreign key referencing an
unsigned primary key (or vice-versa). In this situation you'll have
two choices:
- keep your signed primary key, and pass :unsigned => false when
creating your new foreign key
- update your existing keys to make use of unsigned integers
For example, if we already have a suppliers table with a signed
primary key, and are now creating a products table that will reference
it, we can either create a signed foreign key:
create_table :products do |t|
  # various columns go here
  t.references :supplier, :unsigned => false
end
Or we can change the existing key to be unsigned, like this:
change_table :suppliers do |t|
  t.change :id, :integer, :unsigned => true
end
create_table :products do |t|
  # No need to be signed!
  t.references :supplier
end
So to summarise:
- signed integers are still the default
- *except* for auto-generated primary keys, and foreign keys created
using the 'sexy' references/belongs_to syntax
- unsigned foreign keys can be created by passing :unsigned => false
to references/belongs_to
- existing columns (including primary keys) can be changed to/from
unsigned using change_column
While IPv4 addresses were my inspiration for the patch (as well as
seeing it come up as a requirement on various Rails forums from time
to time) there are probably other situations where having the option
to go unsigned will be helpful. Hopefully we'll hear from some people
who have some other, more interesting, examples
Thanks for the feedback.