The function below keeps returning this error message. I thought that maybe the double_precision field type was what was causing this, and I tried to use CAST, but either that’s not it, or I didn’t do it right… Help?
Here’s the error:
ERROR: input is out of range
CONTEXT: PL/pgSQL function "calculate_distance" line 7 at RETURN
********** Error **********
ERROR: input is out of range
SQL state: 22003
Context: PL/pgSQL function "calculate_distance" line 7 at RETURN
And here’s the function:
CREATE OR REPLACE FUNCTION calculate_distance(character varying,
double precision, double precision,
double precision, double precision)
RETURNS double precision AS
$BODY$
DECLARE earth_radius double precision;
BEGIN
earth_radius := 3959.0;
RETURN earth_radius * acos(sin($2 / 57.2958) *
sin($4 / 57.2958) + cos($2/ 57.2958) * cos($4 / 57.2958)
* cos(($5 / 57.2958) - ($3 / 57.2958)));
END;
$BODY$
LANGUAGE 'plpgsql' VOLATILE
COST 100;
ALTER FUNCTION calculate_distance(character varying,
double precision, double precision, double precision,
double precision) OWNER TO postgres;
//I tried changing (unsuccessfully) that RETURN line to:
RETURN CAST( (earth_radius * acos(sin($2 / 57.2958)
* sin($4 / 57.2958) + cos($2/ 57.2958) * cos($4 / 57.2958)
* cos(($5 / 57.2958) - ($3 / 57.2958))) ) AS text);
asked Mar 28, 2010 at 15:19
Take a look at this solution:
http://www.postgresql.org/message-id/12376732.post@talk.nabble.com
The problem was indeed ACOS() being outside of the [-1,1] range, and
this happened because it was calculating the distance between the same
LAT,LONG pair (the same location)I added a WHERE L1.ID <> L2.ID to stop the reflexive calculation.
Martijn van Oosterhout wrote:
On Sat, Aug 18, 2007 at 03:21:02PM -0700, dustov wrote:
My database just had this new error, and I have no idea why (because I
haven’t intentionally made any changes to this table). Does anyone have
an
idea which input is out of range— or what the problem might be?The only thing in your query that I can imagine being out of range is
ACOS() which would need to be between -1 and 1 (otherwise the result
would be complex).I’d try and see what the argument to the ACOS is, but it’s probably
some corner case where the rounding is getting you.Hope this helps,
I had the same error with calculating the distance between coordinates but the above tip solved my problem.
Fraser
72.9k19 gold badges234 silver badges214 bronze badges
answered Apr 1, 2015 at 13:50
LetokterenLetokteren
7391 gold badge14 silver badges28 bronze badges
0
Little late but had the same problem and it happens because acos param is outside [-1,1] (maybe 1.01)
before calculating ACOS you should cast as INTEGER that value
like this:
RETURN (earth_radius * acos(CAST ((sin($2 / 57.2958)
sin($4 / 57.2958) + cos($2/ 57.2958) * cos($4 / 57.2958)
cos(($5 / 57.2958) - ($3 / 57.2958)) AS INTEGER)) );
answered Apr 4, 2011 at 16:13
wittolfrwittolfr
491 silver badge3 bronze badges
1
It’s due to a floating point rounding error taking the value to >1.
Before taking the ACOS limit the value to the range -1 to 1 with least and greatest
acos(least(greatest(...),-1),1));
Full replacement:
CREATE OR REPLACE FUNCTION calculate_distance(character varying,
double precision, double precision,
double precision, double precision)
RETURNS double precision AS
$BODY$
DECLARE earth_radius double precision;
BEGIN
earth_radius := 3959.0;
RETURN earth_radius *
acos(least(greatest(
sin($2 / 57.2958) *
sin($4 / 57.2958) + cos($2/ 57.2958) * cos($4 / 57.2958)
* cos(($5 / 57.2958) - ($3 / 57.2958))
),-1),1));
END;
$BODY$
LANGUAGE 'plpgsql' VOLATILE
COST 100;
ALTER FUNCTION calculate_distance(character varying,
double precision, double precision, double precision,
double precision) OWNER TO postgres;
answered Mar 14, 2019 at 15:33
Tim AbellTim Abell
10.7k8 gold badges78 silver badges108 bronze badges
I had the same problem and I could not install the contrib modules (I was not the admin).
You can have a look here:
http://en.wikipedia.org/wiki/Great-circle_distance
A numerically stable formula (for non antipodal points) is the following:
RETURN earth_radius * (2.*asin(sqrt((power(sin(radians(($4-$2)/2.)),2))+
(cos(radians($4))*cos(radians($2))*power(sin(radians(($5-$3)/2.)),2)))));
If you need an universal formula you can try to implement the one of the atan2 that is explained in the Wikipedia page.
j0k
22.4k28 gold badges80 silver badges89 bronze badges
answered Apr 5, 2011 at 16:28
0
If coordinates the same you will get exception «[22003] ERROR: input is out of range». To prevent it just catch exception and return 0, like this:
EXCEPTION
WHEN numeric_value_out_of_range
THEN RETURN 0;
answered Oct 23, 2018 at 14:16
RinatRinat
5384 silver badges5 bronze badges
The function below keeps returning this error message. I thought that maybe the double_precision field type was what was causing this, and I tried to use CAST, but either that’s not it, or I didn’t do it right… Help?
Here’s the error:
ERROR: input is out of range
CONTEXT: PL/pgSQL function "calculate_distance" line 7 at RETURN
********** Error **********
ERROR: input is out of range
SQL state: 22003
Context: PL/pgSQL function "calculate_distance" line 7 at RETURN
And here’s the function:
CREATE OR REPLACE FUNCTION calculate_distance(character varying,
double precision, double precision,
double precision, double precision)
RETURNS double precision AS
$BODY$
DECLARE earth_radius double precision;
BEGIN
earth_radius := 3959.0;
RETURN earth_radius * acos(sin($2 / 57.2958) *
sin($4 / 57.2958) + cos($2/ 57.2958) * cos($4 / 57.2958)
* cos(($5 / 57.2958) - ($3 / 57.2958)));
END;
$BODY$
LANGUAGE 'plpgsql' VOLATILE
COST 100;
ALTER FUNCTION calculate_distance(character varying,
double precision, double precision, double precision,
double precision) OWNER TO postgres;
//I tried changing (unsuccessfully) that RETURN line to:
RETURN CAST( (earth_radius * acos(sin($2 / 57.2958)
* sin($4 / 57.2958) + cos($2/ 57.2958) * cos($4 / 57.2958)
* cos(($5 / 57.2958) - ($3 / 57.2958))) ) AS text);
asked Mar 28, 2010 at 15:19
Take a look at this solution:
http://www.postgresql.org/message-id/12376732.post@talk.nabble.com
The problem was indeed ACOS() being outside of the [-1,1] range, and
this happened because it was calculating the distance between the same
LAT,LONG pair (the same location)I added a WHERE L1.ID <> L2.ID to stop the reflexive calculation.
Martijn van Oosterhout wrote:
On Sat, Aug 18, 2007 at 03:21:02PM -0700, dustov wrote:
My database just had this new error, and I have no idea why (because I
haven’t intentionally made any changes to this table). Does anyone have
an
idea which input is out of range— or what the problem might be?The only thing in your query that I can imagine being out of range is
ACOS() which would need to be between -1 and 1 (otherwise the result
would be complex).I’d try and see what the argument to the ACOS is, but it’s probably
some corner case where the rounding is getting you.Hope this helps,
I had the same error with calculating the distance between coordinates but the above tip solved my problem.
Fraser
72.9k19 gold badges234 silver badges214 bronze badges
answered Apr 1, 2015 at 13:50
LetokterenLetokteren
7391 gold badge14 silver badges28 bronze badges
0
Little late but had the same problem and it happens because acos param is outside [-1,1] (maybe 1.01)
before calculating ACOS you should cast as INTEGER that value
like this:
RETURN (earth_radius * acos(CAST ((sin($2 / 57.2958)
sin($4 / 57.2958) + cos($2/ 57.2958) * cos($4 / 57.2958)
cos(($5 / 57.2958) - ($3 / 57.2958)) AS INTEGER)) );
answered Apr 4, 2011 at 16:13
wittolfrwittolfr
491 silver badge3 bronze badges
1
It’s due to a floating point rounding error taking the value to >1.
Before taking the ACOS limit the value to the range -1 to 1 with least and greatest
acos(least(greatest(...),-1),1));
Full replacement:
CREATE OR REPLACE FUNCTION calculate_distance(character varying,
double precision, double precision,
double precision, double precision)
RETURNS double precision AS
$BODY$
DECLARE earth_radius double precision;
BEGIN
earth_radius := 3959.0;
RETURN earth_radius *
acos(least(greatest(
sin($2 / 57.2958) *
sin($4 / 57.2958) + cos($2/ 57.2958) * cos($4 / 57.2958)
* cos(($5 / 57.2958) - ($3 / 57.2958))
),-1),1));
END;
$BODY$
LANGUAGE 'plpgsql' VOLATILE
COST 100;
ALTER FUNCTION calculate_distance(character varying,
double precision, double precision, double precision,
double precision) OWNER TO postgres;
answered Mar 14, 2019 at 15:33
Tim AbellTim Abell
10.7k8 gold badges78 silver badges108 bronze badges
I had the same problem and I could not install the contrib modules (I was not the admin).
You can have a look here:
http://en.wikipedia.org/wiki/Great-circle_distance
A numerically stable formula (for non antipodal points) is the following:
RETURN earth_radius * (2.*asin(sqrt((power(sin(radians(($4-$2)/2.)),2))+
(cos(radians($4))*cos(radians($2))*power(sin(radians(($5-$3)/2.)),2)))));
If you need an universal formula you can try to implement the one of the atan2 that is explained in the Wikipedia page.
j0k
22.4k28 gold badges80 silver badges89 bronze badges
answered Apr 5, 2011 at 16:28
0
If coordinates the same you will get exception «[22003] ERROR: input is out of range». To prevent it just catch exception and return 0, like this:
EXCEPTION
WHEN numeric_value_out_of_range
THEN RETURN 0;
answered Oct 23, 2018 at 14:16
RinatRinat
5384 silver badges5 bronze badges
Содержание
- ОШИБКА 1264 (22003): значение вне диапазона для столбца median_comments в строке 1
- 2 ответа
- ошибка postgresql — ОШИБКА: ввод вне допустимого диапазона
- 6 ответы
- Ошибка MySQL 1264: значение вне допустимого диапазона для столбца
- tl; dr
- Объяснение
- Решение
- Postgres: целое число вне допустимого диапазона. Почему возникает эта ошибка?
- BIGINT UNSIGNED VALUE находится вне диапазона моего SQL
- 7 ответов
ОШИБКА 1264 (22003): значение вне диапазона для столбца median_comments в строке 1
Я получаю такую ошибку:
ОШИБКА 1264 (22003): значение вне диапазона для столбца median_comments в строке 1
После выполнения этого запроса:
Я не уверен, почему это не работает с этим числом, которое не имеет десятичных знаков и состоит всего из 4 цифр.
2 ответа
Вы используете DECIMAL(10,8) , что означает, что максимальное количество цифр перед десятичным будет (10 — = 2 .
Синтаксис объявления для столбца DECIMAL — DECIMAL (M, D). Диапазоны значений аргументов следующие:
- М — максимальное количество цифр (точность). Он имеет диапазон от 1 до 65.
- D — количество цифр справа от десятичной точки (шкала). Он имеет диапазон от 0 до 30 и не должен быть больше M.
Чтобы исправить ошибку, измените тип данных на DECIMAL(10,2) .
Если вы используете десятичный (10,8) в качестве типа данных, это означает, что вы указываете 8 цифр после десятичного разряда, что оставляет только (10-8, т.е. 2 цифры) для всего вашего числа.
В этом случае, поскольку ваш номер 1347 содержит 4 цифры (целое число), вы получаете сообщение об ошибке «Значение вне допустимого диапазона», поскольку вам разрешено только 2.
Вам следует подумать об изменении его как минимум на десятичное (12,8), что даст вам 4 цифры для всей вашей числовой части, и ваша вышеуказанная команда должна работать.
Источник
ошибка postgresql — ОШИБКА: ввод вне допустимого диапазона
Функция ниже продолжает возвращать это сообщение об ошибке. Я подумал, что, возможно, это вызвано типом поля double_precision, и я попытался использовать CAST, но либо это не так, либо я сделал это неправильно. Помогите?
задан 28 марта ’10, 12:03
6 ответы
И какой запрос вы выполняете, чтобы получить эту ошибку?
Вы смотрели вклад? Имеет также функции для этого типа расчеты.
ответ дан 28 мар ’10, в 16:03
Нет, я никогда не видел этого раньше. Хотя выглядит неплохо. У вас есть ссылка или пример того, как это использовать? Мне непонятно, как передать ему радиус, который вы хотите рассчитать (например, если центральная точка находится на -77, 30, и вы хотите найти все точки в радиусе 20 миль) — КофеинIV
Извините, я не могу вам помочь. Просто попробуйте и посмотрите, может ли это решить вашу проблему. — Фрэнк Хайкенс
Немного поздно, но возникла та же проблема, и это происходит потому, что параметр acos находится за пределами [-1,1] (возможно, 1.01), прежде чем вычислять ACOS, вы должны указать это значение как INTEGER
ответ дан 04 апр.
Это не может быть правдой, ты в конечном итоге все сделаешь 0 or 1 — Тим Абелл
Взгляните на это решение:
Проблема действительно заключалась в том, что ACOS() находился за пределами диапазона [-1,1], и это произошло потому, что он вычислял расстояние между одной и той же парой LAT, LONG (то же самое местоположение).
Я добавил WHERE L1.ID <> L2.ID, чтобы остановить рефлексивное вычисление.
Мартин ван Остерхаут писал:
В сб, 18 августа 2007 г., в 03:21:02 -0700:XNUMX, dustov написал:
В моей базе данных только что была эта новая ошибка, и я понятия не имею, почему (потому что я намеренно не вносил никаких изменений в эту таблицу). У кого-нибудь есть идея, какой вход находится вне диапазона или в чем может быть проблема?
Единственное, что я могу представить в вашем запросе вне допустимого диапазона, это ACOS(), значение которого должно быть между -1 и 1 (иначе результат будет сложным).
Я бы попытался посмотреть, каковы аргументы в пользу ACOS, но, вероятно, это какой-то крайний случай, когда округление доставит вас.
Надеюсь, что это помогает,
У меня была такая же ошибка с вычислением расстояния между координатами, но приведенный выше совет решил мою проблему.
Источник
Ошибка MySQL 1264: значение вне допустимого диапазона для столбца
Поскольку я использую SET cust_fax в таблице в MySQL вот так:
а затем я вставляю такое значение:
но потом он говорит
`error 1264` out of value for column
И я хочу знать, где ошибка? Мой набор? Или другой?
Любой ответ будет оценен по достоинству!
Значение 3172978990 больше, чем 2147483647 — максимальное значение для INT — отсюда и ошибка. Здесь перечислены целочисленные типы MySQL и их диапазоны .
Также обратите внимание, что (10) in INT(10) не определяет «размер» целого числа. Он определяет ширину отображения столбца. Эта информация носит рекомендательный характер.
Чтобы исправить ошибку, измените тип данных на VARCHAR . Номера телефона и факса следует хранить в виде строк. См. Это обсуждение .
Вы также можете изменить тип данных на bigInt, и это решит вашу проблему. Не рекомендуется хранить целые числа в виде строк, если в этом нет необходимости. 🙂
Вы превышаете длину типа данных int . Вы можете использовать атрибут UNSIGNED для поддержки этого значения.
SIGNED INT может поддерживать до 2147483647, а с UNSIGNED INT позволяет вдвое больше. После этого вы все еще хотите сохранить данные, чем использовать CHAR или VARCHAR с длиной 10
tl; dr
Убедитесь, что вы AUTO_INCREMENT не находитесь за пределами досягаемости. В этом случае установите для него новое значение:
Объяснение
AUTO_INCREMENT может содержать число, превышающее максимальное значение, разрешенное типом данных. Это может произойти, если вы заполнили стол, который вы опустошили позже, но он AUTO_INCREMENT остался прежним, но также могут быть разные причины. В этом случае идентификатор новой записи будет вне допустимого диапазона.
Решение
Если это причина вашей проблемы, вы можете исправить ее, установив AUTO_INCREMENT на единицу больше, чем идентификатор последней строки. Итак, если идентификатор вашей последней строки равен 100, тогда:
Если вы хотите проверить AUTO_INCREMENT текущее значение, используйте эту команду :
Источник
Postgres: целое число вне допустимого диапазона. Почему возникает эта ошибка?
У меня два вопроса. Я ожидаю, что оба вставят одно и то же значение: 429496729600 , но один из них не работает из-за ошибки:
Почему возникает ошибка при первом запросе?
UPD
Забудьте указать, что тип amount — это bigint , а
Ваше число больше целого. Перед вставкой первой вставки выполняется вычисление. Когда вы умножаете целое число, postgres ожидает в качестве результата целое число. Это не так.
int максимальное значение 2 31 -1, первое значение обновления больше, чем оно, поэтому вызывает ошибку.
Вы можете попробовать сделать столбец amount для типа BIGINT
BIGINT -9223372036854775808 to 9223372036854775807
РЕДАКТИРОВАТЬ
мы можем использовать pg_typeof , чтобы проверить это.
Запрос №1
postgresql позволит 429496729600 быть BIGINT из-за значения, превышающего диапазон int.
Запрос №2
Когда вы делаете умножение на число, которое будет переведено в int .
Запрос
Вы можете использовать 400*1024*1024*1024:: BIGINT , позволяя int конвертировать в bigint .
хорошо спасибо. Покажи мне проблему. но другой ответ покажет, как решить эту проблему.
Источник
BIGINT UNSIGNED VALUE находится вне диапазона моего SQL
Я получаю следующую ошибку
#1690-значение без знака BIGINT находится вне диапазона в ‘ ( legends . spawns . quantity — tmp_field )’
Я смотрел на него некоторое время, запрос длинный, извините.
порождает таблицу-count game_moblist.spawn_id is 0 для всех возможных строк, кроме 1 (я удалил строку, чтобы проверить запрос)
данные в противном случае довольно длинные и не имеют отношения к моему вопросу Я думаю
любые идеи, как обойти эту ошибку?
7 ответов
начиная с MySQL 5.5.5, переполнение во время оценки числового выражения приводит к ошибке. Например, наибольшее значение bigint со знаком 9223372036854775807, поэтому следующее выражение создает ошибку.
чтобы операция прошла успешно, преобразуйте значение unsigned;
изменение части вашего запроса, как показано ниже, решит проблему.
в противном случае вам может потребоваться изменить sql_mode о неподписанных операций.
а затем запустите запрос, чтобы получить желаемый результат.
см. также аналогичную публикацию на форуме здесь.
Я действительно нашел этот вопрос, почему я искал решение. Если у вас такая же проблема, как и у меня, попробуйте отключить параметр «unsigned».
вполне возможно, что ваш код не здесь:
потому что, если результат этой математической операции меньше нуля, он потерпит неудачу с параметром «unsigned».
У меня была та же проблема, она произошла на соединении и не могла понять, что происходит, в конце концов, это была опечатка в предложении ON, где я поместил знак минус вместо знака равенства. Может быть, глупо, но я просто не видел этого около 30 минут, и, возможно, это может кому-то помочь.
дополнительный способ-использовать MySQL, если оператора. Это помогло мне, когда оба столбца были BIGINT and Unsigned .
другой возможной причиной, по-видимому, является то, как выделяется тип переменной результата.
ошибка 1690 (22003): значение без знака BIGINT находится вне диапазона в ‘(1 — ((1 / 1.045) ^ markov . tbl_EUR_PDH . term_06 ))’
делает то, что можно было бы ожидать (обратите внимание, что я просто заменяю «1»на » 1.0″)
чтобы обобщить правило, MySQL теперь откажется вычитать беззнаковый операнд из подписанного.
пример : SELECT A — B; завершится ошибкой, если A подписан, А B-без знака.
обходные пути: добавьте фактор 1.0 в подписанный операнд, чтобы он неявно бросал его в FLOAT или использовал CAST (B AS SIGNED) , или даже swap (B — A) и измените алгоритм соответствующим образом.
sql_mode работал в mysql client и Adminer, но не в CodeIgniter, где это считается. Кастинг тоже не помог.
простая арифметическая операция сделала трюк:
Источник
Problem
I’m running a stream which uses a SQL Source node. The datasource uses the SQL Server Native Client 10.0 ODBC driver.
The table in the SQL Server 2008 database has a decimal 15,5 field.
Running the stream gives below error.
Error Message: 22003 [Microsoft][SQL Server Native Client 10.0]Numeric value out of range
Resolving The Problem
This problem has been reported to SPSS Development — Workaround Available
This is working as designed.
As a workaround, use float instead of decimal.
More information about he use of float and decimal can be found in the Help of SQL Server 2008
Related Information
[{«Product»:{«code»:»SS3RA7″,»label»:»IBM SPSS Modeler»},»Business Unit»:{«code»:»BU059″,»label»:»IBM Software w/o TPS»},»Component»:»Modeler»,»Platform»:[{«code»:»PF033″,»label»:»Windows»}],»Version»:»13.0″,»Edition»:»»,»Line of Business»:{«code»:»LOB10″,»label»:»Data and AI»}}]
I’m having essentially the same issue as in #227, except the posted solution does nothing to fix it for me.
I should note that these integers represent date-and-time information, so 18-03-03 23:59:24 —> 180303235924, etc. The information should thus perhaps rather be stored it string form, so I tried casting typt integer to string, but that did not work either.
Is this unexpected behaviour or am I simply showing my SQL inexperience?
With «cast» (bigint) command output example:
pgloader --cast "type integer to bigint" 04-03-2018.db postgresql:///mapping
2018-03-07T21:10:53.872000Z ERROR PostgreSQL ["points"] Database error 22003: value "180303235924" is out of range for type integer
CONTEXT: COPY points, line 1, column gps_time: "180303235924"
2018-03-07T21:10:53.872000Z ERROR PostgreSQL ["points"] Database error 22003: value "180303235930" is out of range for type integer
CONTEXT: COPY points, line 1, column gps_time: "180303235930"
2018-03-07T21:10:53.872000Z ERROR PostgreSQL ["points"] Database error 22003: value "180303235926" is out of range for type integer
CONTEXT: COPY points, line 1, column gps_time: "180303235926"
2018-03-07T21:10:54.072000Z ERROR PostgreSQL ["points"] Database error 22003: value "180303235927" is out of range for type integer
CONTEXT: COPY points, line 1, column gps_time: "180303235927"
2018-03-07T21:10:54.073000Z ERROR PostgreSQL ["points"] Database error 22003: value "180303235929" is out of range for type integer
CONTEXT: COPY points, line 1, column gps_time: "180303235929"
^Z
[31]+ Stopped pgloader --cast "type integer to bigint" 04-03-2018.db postgresql:///mapping
With «cast» (string) command output example:
pgloader --cast "type integer to string" 04-03-2018.db postgresql:///mapping
2018-03-07T20:49:46.652000Z ERROR PostgreSQL ["points"] Database error 22003: value "180303235924" is out of range for type integer
CONTEXT: COPY points, line 1, column gps_time: "180303235924"
2018-03-07T20:49:46.655000Z ERROR PostgreSQL ["points"] Database error 22003: value "180303235930" is out of range for type integer
CONTEXT: COPY points, line 1, column gps_time: "180303235930"
2018-03-07T20:49:46.655000Z ERROR PostgreSQL ["points"] Database error 22003: value "180303235926" is out of range for type integer
CONTEXT: COPY points, line 1, column gps_time: "180303235926"
2018-03-07T20:49:46.655000Z ERROR PostgreSQL ["points"] Database error 22003: value "180303235927" is out of range for type integer
CONTEXT: COPY points, line 1, column gps_time: "180303235927"
2018-03-07T20:49:46.656000Z ERROR PostgreSQL ["points"] Database error 22003: value "180303235929" is out of range for type integer
CONTEXT: COPY points, line 1, column gps_time: "180303235929"
^Z
[29]+ Stopped pgloader --cast "type integer to string" 04-03-2018.db postgresql:///mapping
Without «cast» command output example:
pgloader 04-03-2018.db postgresql:///mapping
2018-03-07T21:04:31.680000Z ERROR PostgreSQL ["points"] Database error 22003: value "180303235924" is out of range for type integer
CONTEXT: COPY points, line 1, column gps_time: "180303235924"
2018-03-07T21:04:31.682000Z ERROR PostgreSQL ["points"] Database error 22003: value "180303235930" is out of range for type integer
CONTEXT: COPY points, line 1, column gps_time: "180303235930"
2018-03-07T21:04:31.682000Z ERROR PostgreSQL ["points"] Database error 22003: value "180303235926" is out of range for type integer
CONTEXT: COPY points, line 1, column gps_time: "180303235926"
2018-03-07T21:04:31.682000Z ERROR PostgreSQL ["points"] Database error 22003: value "180303235927" is out of range for type integer
CONTEXT: COPY points, line 1, column gps_time: "180303235927"
2018-03-07T21:04:31.682000Z ERROR PostgreSQL ["points"] Database error 22003: value "180303235929" is out of range for type integer
CONTEXT: COPY points, line 1, column gps_time: "180303235929"
^Z
[30]+ Stopped pgloader 04-03-2018.db postgresql:///mapping
Version:
pgloader --version
pgloader version "3.4.1"
compiled with SBCL 1.3.3.debian