Невозможно вставить значения в атрибут типа bytea при переходе с postgres 7.4 на postgres 9.2

Я переношу приложение с postgres 7.4 на postgres 9.2. Запрос, который отлично работал для вставки значений атрибутов типа bytea в postgres 7.4, выдает PSQLException с приведенной ниже ошибкой в ​​postgres 9.2.

ОШИБКА: синтаксическая ошибка в или рядом с "\" СТРОКА 1: ...07\000\000\001\002\000\000|\012\000\000\'\007\000... (Ошибка отображается рядом одинарная кавычка)

*** Ошибка ***

ОШИБКА: синтаксическая ошибка в или около "\" Состояние SQL: 42601 Символ: 39081

Я прочитал документацию postgres о bytea_output, для которого можно установить значение «escape», чтобы вывести содержимое атрибута в формате escape. Также упоминается, что атрибуты типа bytea могут принимать как escape-, так и шестнадцатеричный формат.

Поскольку приложение ранее использовало postgres 7.4, мы используем escape-формат. Интересно, почему возникает эта ошибка, если bytea может принимать как escape-, так и шестнадцатеричный формат в postgres 9.2. Пожалуйста, помогите в решении этой ошибки.


person Muthu    schedule 02.09.2013    source источник
comment
Вы используете драйвер JDBC версии 9.2?   -  person a_horse_with_no_name    schedule 02.09.2013
comment
Я выполнил запрос от pgAdmin и получил вышеупомянутую ошибку.   -  person Muthu    schedule 02.09.2013
comment
Пожалуйста, покажите нам полный запрос. И вы убедились, что версия pgAdmin подходит для работы с Postgres 9.2?   -  person a_horse_with_no_name    schedule 02.09.2013


Ответы (1)


bytea_output указывает формат содержимого bytea в выходных столбцах, а не при отправке как часть оператора SQL. Как вы уже догадались, это, вероятно, не имеет значения здесь.

Тем не менее, что может иметь значение, так это тот факт, что standard_conforming_strings был включен по умолчанию с PG 9.1 (я не думаю, что он даже существовал в 7.4), поэтому вы больше не можете использовать обратную косую черту, чтобы избежать одиночной кавычки внутри литерала.

См. флаги совместимости и пояснения в документе 9.2: Предыдущие версии PostgreSQL, особенно backslash_quote, escape_string_warning и standard_conforming_strings.

Если не считать исправления вашего приложения, простой способ решить проблему — отключить standard_conforming_strings и escape_string_warning, если количество предупреждений в журналах проблематично (на самом деле это предупреждение в основном полезно в процессе исправления вашего приложения до стандарта). соответствие строк).

Это можно сделать глобально в файле postgresql.conf, который находится в каталоге данных. См. Настройка параметров в документе.

standard_conforming_strings=off  
escape_string_warning=off
person Daniel Vérité    schedule 02.09.2013
comment
Спасибо за ваше предложение. Подскажите, пожалуйста, как отключить эти флаги совместимости. - person Muthu; 03.09.2013
comment
@ user2416545: добавлено в ответ. - person Daniel Vérité; 03.09.2013
comment
Я установил «standard_conforming_strings=off», «escape_string_warning=off», «backslash_quote=off» и «bytea_output=escape» в файле postgresql.conf и перезапустил сервер. Я все еще получаю ту же ошибку, когда пытаюсь вставить значения в атрибуты bytea. Любое другое обходное решение для этого? - person Muthu; 04.09.2013
comment
@user2416545: backslash_quote=off причина. Обратите внимание, что я предложил отключить два других, а не этот. - person Daniel Vérité; 04.09.2013
comment
Та же ошибка, если я сохраняю backslash_quote=on и backslash_quote=safe-encoding. Я не понимаю, где я ошибаюсь. - person Muthu; 04.09.2013
comment
@ user2416545: можете ли вы обновить вопрос с ошибкой или ее отсутствием, которая возникает на простом select 'ab\'cd'::bytea;? Также вы можете перепроверить значения standard_conforming_strings и другие настройки в клиенте с помощью show standard_conforming_strings. - person Daniel Vérité; 04.09.2013
comment
Я использовал show standard_conforming_strings, чтобы получить текущий статус, и отключил его с помощью запроса set standard_conforming_strings=off. Теперь запрос на вставку работает нормально. Спасибо Даниэлю Верите за помощь в решении этой проблемы. - person Muthu; 06.09.2013