Strange Heroku float bit-precision error (ruby on

Question

Originally a coordinate field on my model was using integer, but when I tried to deploy to Heroku, I was reminded (by a crash) that I needed it to be a float instead (since I had decimal points in my coordinate). So I generated a change_column migration on my local machine, to change_column them to be floats instead. and everything went fine.

I tried to deploy to heroku again, first with a heroku pg:reset and then with a heroku db:setup. During the db:setup, I get the following error:

PGError: ERROR: precision for type float must be less than 54 bits : CREATE TABLE "landmarks" ("id" serial primary key, "name" character varying(255), "xcoord" float(255), "ycoord" float(255), "created_at" timestamp, "updated_at" timestamp)

So I generated another change_column migration, this time with :precision option as well (set to :precision => 50, which is less than 54). I went through the whole deploy process again, and it gave me the same error.

Am I doing something wrong? I've deployed another app to Heroku before that used float without any modification...

I'm using SQLite on my local machine, and I think Heroku uses Postgres?

Thanks in advance!

[EDIT: I should also mention that the output SQL the error displayed after I changed the :precision value for my coords still said 'float(255)'...not sure why]

Answer 1

I think Postgres is complaining about the difference between bits and digits - something that has 50 digits of precision has far more than 50 bits. Put another way, 2^53 = 9,007,199,254,740,992, or 16 significant digits of accuracy. Try setting it to :scale => 12, :precision => 15 - that should get you three digits before the decimal point, and 12 digits after, and I believe that puts you under the 53-bit limit.

Answer 2

Don't use float(255) as the column type. Use either real or double precision. Please read http://www.postgresql.org/docs/8.3/static/datatype-numeric.html#DATATYPE-FLOAT

Also we strongly recommend using postgres locally for development. It is all too common to run into inconsistencies—such as this—when drastically switching important parts of your stack between development and production. And your database is an important part of your stack.