Нет, это нигде не зарегистрировано. Пойди проголосуй и изложи свое экономическое обоснование; это один из длинного списка вещей, которые должны быть исправлены в SQL Server.
Это было запрошено несколько лет назад в Connect (возможно, сначала в период SQL Server 2000 или 2005), а затем снова в новой системе обратной связи:
И теперь он поставляется в SQL Server 2019 , SQL Server 2017 CU12 и появится в будущем SQL Server 2016 SP2 CU.
В самой первой общедоступной CTP-версии SQL Server 2019 он отображается только под флагом трассировки 460. Это звучит как секрет, но он был опубликован в этом техническом описании Microsoft . В дальнейшем это будет поведение по умолчанию (флаг трассировки не требуется), хотя вы сможете управлять этим через новую конфигурацию области базы данных VERBOSE_TRUNCATION_WARNINGS
.
Вот пример:
USE tempdb;
GO
CREATE TABLE dbo.x(a char(1));
INSERT dbo.x(a) VALUES('foo');
GO
Результат во всех поддерживаемых версиях до SQL Server 2019:
Сообщение 8152, уровень 16, состояние 30, строка 5
Строка или двоичные данные будут обрезаны.
Заявление было прекращено.
Теперь на CTP-серверах SQL Server 2019 с включенным флагом трассировки:
DBCC TRACEON(460);
GO
INSERT dbo.x(a) VALUES('foo');
GO
DROP TABLE dbo.x;
DBCC TRACEOFF(460);
Результат показывает таблицу, столбец и значение ( усеченное , не полное ):
Сообщение 2628, уровень 16, состояние 1, строка 11
Строка или двоичные данные будут обрезаны в таблице «tempdb.dbo.x», столбец «a». Усеченное значение: 'f'.
Заявление было прекращено.
Пока вы не можете отбросить все и выполнить обновление до SQL Server 2019 или перейти на базу данных SQL Azure, вы можете изменить свой «автоматический» код, чтобы фактически получать значение max_length sys.columns
вместе с именем, которое вы все равно должны получить, а затем применять LEFT(column, max_length)
или какой бы ни был эквивалент PG. Или, поскольку это просто означает, что вы будете молча терять данные, выясните, какие столбцы не совпадают, и исправьте столбцы назначения, чтобы они соответствовали всем данным из источника. Учитывая доступ к метаданным в обеих системах и тот факт, что вы уже пишете запрос, который должен автоматически сопоставлять столбцы источника -> назначения (в противном случае эта ошибка вряд ли будет вашей самой большой проблемой), вам не нужно делать никакой грубой силы гадать на всех.
sys.columns
потому что я совершенно не представлял, какой код вы сейчас используете для «автоматического» генерирования ваших запросов. Там действительно не так много сложнее, я мог бы догадаться о включении в ваш код, чемSELECT name, object_id, max_length FROM sys.columns;
. Поскольку у вас уже есть автоматический код, который должен это делать - или что-то очень похожее - я не думаю, что пример необходим.