Current migrations fail with PostgreSQL
Using the tracks-1.5rc1 SVN tag the PostgreSQL migration fails:
h2. =================
-- change_column(:projects, :position, :integer, {:default=>false, :null=>true})
rake aborted!
PGError: ERROR: invalid input syntax for integer: "f"
: ALTER TABLE projects ALTER COLUMN "position" SET DEFAULT 'f'
Leave a comment
on 2008-03-16 15:52 *
By Anonymous
Assigned to changed from bsag to Anonymous
Milestone set to 1.5
Status changed from New to Accepted
Assigned to changed from bsag to Anonymous
Milestone set to 1.5
Status changed from New to Accepted
looks like a rails issue, since we 'solved' #640 with [722].
We really need to go to rails2.0 after releasing 1.5
We really need to go to rails2.0 after releasing 1.5
I don't think this has anything to do with rails versions. The migration is setting the default value of an integer column to false. That may fall through the cracks on some of the lesser databases, but that doesn't make it correct!
change_column :projects, :position, :integer, {:null => true, :default => false}
change_column :contexts, :position, :integer, {:null => true, :default => false}
that doesn't mean "don't have a default" it means the default is false!
change_column :projects, :position, :integer, {:null => true, :default => false}
change_column :contexts, :position, :integer, {:null => true, :default => false}
that doesn't mean "don't have a default" it means the default is false!
The default default value is NULL, so setting :default => nil would do the trick
From the postgres docs:
"If no default value is declared explicitly, the default value is the null value. This usually makes sense because a null value can be considered to represent unknown data."
From the postgres docs:
"If no default value is declared explicitly, the default value is the null value. This usually makes sense because a null value can be considered to represent unknown data."