Por que uma coluna de texto não pode ter um valor padrão no MySQL?

Se você tentar criar uma coluna TEXT em uma tabela e atribuir a ela um valor padrão no MySQL, você receberá um erro (pelo menos no Windows). Não vejo nenhum motivo para uma coluna de texto não ter um valor padrão. Nenhuma explicação é dada na documentação do MySQL. Parece ilógico para mim (e um tanto frustrante, pois quero um valor padrão!). Alguém sabe por que isso não é permitido?

O Windows MySQL v5 gera um erro, mas o Linux e outras versões apenas emitem um aviso. Isso precisa ser corrigido. WTF?

Veja também uma tentativa de corrigir isso como bug # 19498 no MySQL Bugtracker:

Bryce Nesbitt em 4 de abril de 2008 16:36:
No MS Windows, a regra "no DEFAULT" é um erro, enquanto em outras plataformas geralmente é um aviso. Embora não seja um bug, é possível ficar preso a isso se você escrever código em uma plataforma branda e depois executá-lo em uma plataforma estrita:

Pessoalmente, vejo isso como um bug. A pesquisa por "coluna BLOB / TEXT não pode ter um valor padrão" retorna cerca de 2.940 resultados no Google. A maioria deles são relatórios de incompatibilidades ao tentar instalar scripts de banco de dados que funcionavam em um sistema, mas não em outros.

Estou enfrentando o mesmo problema agora em um aplicativo da web que estou modificando para um dos meus clientes, originalmente implantado no Linux MySQL v5.0.83-log. Estou executando o Windows MySQL v5.1.41. Mesmo tentando usar a versão mais recente do phpMyAdmin para extrair o banco de dados, ele não informa um padrão para a coluna de texto em questão. No entanto, quando tento executar uma inserção no Windows (que funciona bem na implantação do Linux), recebo um erro sem padrão na coluna ABC. Tento recriar a tabela localmente com o padrão óbvio (com base em uma seleção de valores exclusivos para essa coluna) e acabo recebendo a coluna BLOB / TEXT tão útil que não pode ter um valor padrão .

Novamente, não manter a compatibilidade básica entre plataformas é inaceitável e é um bug.

Como desativar o modo estrito no MySQL 5 (Windows):

• Edite /my.ini e procure a linha

  sql-mode="STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"

• Substitua por

  sql_mode='MYSQL40'

• Reinicie o serviço MySQL (assumindo que seja mysql5)

  net stop mysql5
  net start mysql5

Se você tiver acesso root / admin, poderá executar

mysql_query("SET @@global.sql_mode='MYSQL40'");

Sem nenhum conhecimento profundo do mecanismo mySQL, eu diria que isso soa como uma estratégia de economia de memória. Presumo que o motivo esteja por trás deste parágrafo nos documentos :

Cada valor BLOB ou TEXT é representado internamente por um objeto alocado separadamente. Isso contrasta com todos os outros tipos de dados, para os quais o armazenamento é alocado uma vez por coluna quando a tabela é aberta.

Parece que o pré-preenchimento desses tipos de coluna levaria a penalidades de uso e desempenho de memória.

Você pode obter o mesmo efeito que um valor padrão usando um gatilho

create table my_text

(
   abc text
);

delimiter //
create trigger mytext_trigger before insert on my_text
for each row
begin
   if (NEW.abc is null ) then
      set NEW.abc = 'default text';
   end if;
end
//
delimiter ;

Como a questão principal:

Alguém sabe por que isso não é permitido?

ainda não foi respondido, fiz uma pesquisa rápida e encontrei uma adição relativamente nova de um desenvolvedor MySQL no MySQL Bugs :

[17 de março de 2017 15:11] Ståle Deraas

Postado por desenvolvedor:

Esta é realmente uma solicitação de recurso válida e, à primeira vista, pode parecer trivial adicionar. Mas os valores TEXT / BLOBS não são armazenados diretamente no buffer de registro usado para ler / atualizar tabelas. Portanto, é um pouco mais complexo atribuir valores padrão a eles.

Esta não é uma resposta definitiva, mas pelo menos um ponto de partida para o porquê pergunta que.

Enquanto isso, vou apenas codificá-lo e tornar a coluna anulável ou atribuir explicitamente um ''valor (padrão ) para cada um insertdo código do aplicativo ...

"Suporte para DEFAULT em colunas TEXT / BLOB" é uma solicitação de recurso no MySQL Bugtracker (Bug # 21532) .

Vejo que não sou o único que gostaria de colocar um valor padrão em uma coluna TEXT. Eu acho que esse recurso deve ser suportado em uma versão posterior do MySQL.

Isso não pode ser corrigido na versão 5.0 do MySQL, porque aparentemente causaria incompatibilidade e dataloss se alguém tentasse transferir um banco de dados entre os bancos de dados (atuais) que não suportam esse recurso e os bancos de dados que suportam esse recurso.

Normalmente, executo sites no Linux, mas também desenvolvo em uma máquina Windows local. Eu já tive esse problema várias vezes e apenas consertei as tabelas quando encontrei os problemas. Eu instalei um aplicativo ontem para ajudar alguém e, claro, encontrou o problema novamente. Então, decidi que era hora de descobrir o que estava acontecendo - e encontrei esse tópico. Eu realmente não gosto da idéia de alterar o sql_mode do servidor para um modo anterior (por padrão), então criei uma solução simples (eu acho).

É claro que esta solução exigiria que os desenvolvedores agrupassem seus scripts de criação de tabela para compensar o problema do MySQL em execução no Windows. Você verá conceitos semelhantes nos arquivos de despejo. Uma ressalva BIG é que isso pode / causará problemas se o particionamento for usado.

// Store the current sql_mode
mysql_query("set @orig_mode = @@global.sql_mode");

// Set sql_mode to one that won't trigger errors...
mysql_query('set @@global.sql_mode = "MYSQL40"');

/**
 * Do table creations here...
 */

// Change it back to original sql_mode
mysql_query('set @@global.sql_mode = @orig_mode');

É sobre isso.

Para o Ubuntu 16.04:

Como desativar o modo estrito no MySQL 5.7:

Edite o arquivo /etc/mysql/mysql.conf.d/mysqld.cnf

Se a linha abaixo existir no mysql.cnf

sql-mode="STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"

Em seguida, substitua-o por

sql_mode='MYSQL40'

De outra forma

Basta adicionar a linha abaixo no mysqld.cnf

sql_mode='MYSQL40'

Este problema foi resolvido.