CartoDB SQL Import API doesn't like columns with a . in them

[talos]

When I try to import a new table using CartoDB SQL import API (via GDAL), if that table has a column named with a . (like b27001050.5) then the import fails:

ERROR 1: Error returned by server : CDB(_CDB_Rewrite_Table:42601:syntax error at or near ".5"): CREATE TABLE jkrauss.census_extract_0 AS SELECT cartodb_id,the_geom,the_geom_webmercator,geoid,b01001001,b01001002,b01001003,b01001004,b01001005,b01001006,b01001007,b01001008,b01001009,b01001010,b01001011,b01001012,b01001013,b01001014,b01001015,b01001016,b01001017,b01001018,b01001019,b01001020,b01001021,b01001022,b01001023,b01001024,b01001025,b01001026,b01001027,b01001028,b01001029,b01001030,b01001031,b01001032,b01001033,b01001034,b01001035,b01001036,b01001037,b01001038,b01001039,b01001040,b01001041,b01001042,b01001043,b01001044,b01001045,b01001046,b01001047,b01001048,b01001049,b01002000.5,b01002001,b01002002,b01002003,b03002001,b03002002,b03002003,b03002004,b03002005,b03002006,b03002007,b03002008,b03002009,b03002010,b03002011,b03002012,b03002013,b03002014,b03002015,b03002016,b03002017,b03002018,b03002019,b03002020,b03002021,b05001001,b05001002,b05001003,b05001004,b05001005,b05001006,b05011001,b05011002,b05011003,b05011004,b05011005,b05011006,b05011007,b05011008,b05011009,b05011010,b05011011,b07101001,b07101002,b07101003,b07101004,b07101004.5,b07101005,b07101006,b07101007,b07101008,b07101009,b07101010,b07101011,b07101012...

My gut says that each column in the SELECT should be quoted inside ". Tagged @javisantana as per @andrewbt's suggestion.

[andrewbt]

Clarification - the ogr2ogr CartoDB driver doesn't touch the Import API at all to my knowledge, it's 100% SQL API. So the bug if it exists may actually be there or the ogr2ogr driver. @pramsey any insight?

[javisantana]

yes, ogr2ogr uses the sql api but i think this is because the cartodbification

[jgoizueta]

I'm fixing this on the cartodb PostgreSQL extension: CartoDB/cartodb-postgresql@ea9503b
CartoDB/cartodb-postgresql@83ac8f4

[jgoizueta]

Version 0.11.4, which fixes this was deployed in production to all user DBs on 2015-11-27.

[talos]

Awesome, thank you. 👍