Код: Выделить всё
CREATE TABLE SOME_TABLE (
ID INTEGER NOT NULL,
NAME VARCHAR(50) NOT NULL)
Код: Выделить всё
INSERT INTO SOME_TABLE (ID, NAME)
VALUES (1, 'Здесь 17 символов')
Ибо нехрен лазить в системных таблицах грязными рукамиCyberMax писал(а):Возможно, данный случай есть в трекере.
Таблица:Запись:Код: Выделить всё
CREATE TABLE SOME_TABLE ( ID INTEGER NOT NULL, NAME VARCHAR(50) NOT NULL)Меняем длину поля NAME c 50 до 10 символов. При открытии таблицы сервер пишет о переполнении (что естественно), а при создании индекса по полю NAME:Код: Выделить всё
INSERT INTO SOME_TABLE (ID, NAME) VALUES (1, 'Здесь 17 символов')
"internal gds software consistency check (can't continue after bugcheck).".
Например, если обновленные бизнес-правила ограничивают длину varchar-поля меньшей длиной.hvlad писал(а):Зачем вообще уменьшать р-р varchar поля ???
. Легальной команды смены домена не дали, но разрешили (или закрыли глаза на нее?) возможность менять его путем применения проктологических инструментов в виде IBE 
.Вотпусть бизнес-правила и ограничивают. При чём тут физика храненияCyberMax писал(а):Например, если обновленные бизнес-правила ограничивают длину varchar-поля меньшей длиной.hvlad писал(а):Зачем вообще уменьшать р-р varchar поля ???
RTFM: ALTER TABLE ALTER COLUMNCyberMax писал(а):Да и дело-то не в смене длины varchar, а в концепции
разве что с эксклюзивной блокировкой всей таблицы с момента ALTER и до коммитаCyberMax писал(а):могут ли в будущем сделать проверку при ALTER COLUMN varchar-поля в сторону уменьшения длины на невыход фактических длин строк поля за указанные пределы и принятия изменения в случае положительного результата?
Сложно сказать. Надёжнее считать, что таки естьCyberMax писал(а):Кстати, Влад, есть какие-нибудь гарантированные побочные явления, когда длина varchar-поля меняется в меньшую сторону через вот такую правку систаблиц?
А оно надо ?CyberMax писал(а):И могут ли в будущем сделать проверку при ALTER COLUMN varchar-поля в сторону уменьшения длины на невыход фактических длин строк поля за указанные пределы и принятия изменения в случае положительного результата?
CyberMax писал(а):И могут ли в будущем сделать проверку при ALTER COLUMN varchar-поля в сторону уменьшения длины на невыход фактических длин строк поля за указанные пределы и принятия изменения в случае положительного результата?
объясняю двадцатый раз:Tonal писал(а):Стартанули снапшот, проверили длинны, если блоьше - откатились, меньше alter table... + commit.
В чём проблемы?
Но ведь сервер не дает изменить тип поля, если на него есть ссылки?kdv писал(а):4. про столбцы с зависимостями, индексами и т.п. я вообще умолчу.
Если нет существующих записей с данными, выходящими за пределы размерности - то индекс создается без проблем.kdv писал(а):2. индекс всегда при создании "видит" все версии
Не соглашусь. Например, преобразование из SmallInt в Integer, из Integer в BigInt, а также Varchar(10) в Varchar(50), то есть в сторону увеличения - в настоящее время разрешено, а вот обратно - запрещено, по причине того, что неизвестно - будет ли потеря данных из-за усечения, или нет.kdv писал(а):5. если делать проверку, то делать для любых преобразований типов из типа А в тип Б, а не только на длину строки.
версионность. ты хоть не прикидывайся.Чем мешают удаленные записи?
Фактически, с этим прекрасно может справиться и сервер. Выходит, вопрос только в том, надо ли это разработчикам и пользователям?kdv писал(а):1. проверить конвертируемость на cast, для всех записей (fetchall)
2. убедиться что в данный момент нет застрявшей транзакции, которая чего-то модифицировала в противоречии с пунктом 1
3. если перед этим было массовое удаление или модификация записей, вы должны понимать что запрос п.1 может привести к сборке мусора (и лучше если приведет, чем оставит какие-нибудь древние версии с нарушением пункта 1)
то есть, фактически это делается в монопольном режиме.
