postgreSQL & PL / pg SQL: значение слишком велико для varchar (36), но вчера я расширил поле до 60 - PullRequest
0 голосов
/ 03 марта 2020

Я настраиваю базу данных, в которую импортирую электронные таблицы .xlsx. По пути я столкнулся с проблемами длины полей и при необходимости расширил поля. До сих пор об этом позаботились.

Сегодня я получил следующее сообщение:

ERROR:  value too long for type character varying(36)
CONTEXT:  SQL statement "INSERT INTO nvschema.txtdata (tuid, customersamplenumber, samplenumber, sample_id_db, location, sampledate, sampletime, qaqc_type, datasource, laboratory)
                       VALUES (theuid, str1, str4, str5 || '_' || str2 || str3 || '_' || str6, str5, str2, str3, str6, str7,str8)"
PL/pgSQL function nvschema.pivot_raw2txt() line 223 at SQL statement
PL/pgSQL function nvschema.rebuild_analyses() line 10 at assignment
SQL state: 22001

Здесь меня смущают две вещи:

  1. Ссылка на строку 223 расходится с оператором SQL, указанным в КОНТЕКСТЕ. Строка 223 функции pivot_raw2txt () вообще не имеет SQL - это присвоение значения целочисленной переменной. 222 случайно имеет другой оператор INSERT, ссылающийся на другую таблицу. Оператор SQL, цитируемый в КОНТЕКСТЕ, - одиннадцатью строками позже, в 234. Любая идея, почему было бы это расхождение в номере строки?

  2. Поле, о котором идет речь, я довольно конечно, это sample_id_db. Вчера была ширина 36, но я расширил ее до 60, чтобы вместить более длинные струны. Со вчерашнего дня я перезапустил и pgAdmin, и сервис postgreSQL, но что-то все еще думает, что поле имеет ширину 36. На самом деле, в txtdata с шириной 36 нет полей varchar в любой из моих таблиц. Что может быть источником проблемы «все еще думает, что это 36»?

PostgreSQL 11, и кодировка UTF-8, если это имеет значение.

Обновление: эта база данных должна быть прочитана через связанные таблицы в другом программном обеспечении. Создание связанных таблиц является громоздким и должно выполняться каждый раз, когда изменяется ширина поля. Удобно установить sh ширины полей, которые шире, чем ожидаемые данные, и оставить все как есть.

Update2: Думая, что с таблицей может быть что-то не так, я выбрал ее каскадно и перестроен, снова с шириной поля 60. Идентичный результат при выполнении вставки.

Ответы [ 2 ]

1 голос
/ 04 марта 2020

Почему ваш 'sample_id_db' имеет фиксированную ширину, в этом нет никакой цели. Просто позвольте Postgresql работать на лету -

создать таблицу xxx (sample_id_db VARCHAR, et c)

0 голосов
/ 04 марта 2020

Должно быть очевидно, но ...

Я выпустил ALTER TABLE sql из pgAdmin, и он действительно меняет ширину поля на 60. Однако ...

В функция PL / pg SQL, я УДАЛЯЮ nvschema.txtdata и использую CREATE TABLE, чтобы восстановить ее. Я УДАЛЯЮ / СОЗДАЮ, а не просто удаляю записи, потому что таблица может иметь разные поля от одного вызова функции до следующего. Во всяком случае, в этой перестройке ширина поля указана как 36.

Я подозреваю, как указывалось выше, что изменение в функции PL / pg SQL ширины 36 не зафиксировано, и после ошибка ширины поля с оператором INSERT, все возвращается к исходному состоянию. Таким образом, когда я смотрю на структуру таблицы, она показывает ширину поля 60 ... как это было до вызова функции.

Когда я изменил ширину поля в операторе CREATE TABLE в PL / pg SQL, все работает.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...