Perguntas frequentes

Não. Quando você clica em Formatar, o seu SQL é enviado ao nosso servidor, formatado em memória e devolvido na mesma resposta. Ele não é gravado em banco de dados, arquivo ou log, e não é compartilhado com parceiros de análise ou de publicidade. Mesmo assim, use qualquer ferramenta online com cuidado: não cole credenciais, dados de clientes nem nada que você não tenha permissão para compartilhar. A página de privacidade descreve tudo o que o site registra.

É gratuito e não há conta, cadastro nem login. Você abre o formatador, cola o seu SQL e formata. O site exibe anúncios, que estão descritos na página de privacidade.

Sim. Os cookies essenciais guardam o seu idioma, o tema e a sua escolha sobre cookies. Um cookie de identificador de sessão só é criado depois que você escolhe "Aceitar todos" ou "Somente essenciais"; ele não tem prazo de validade fixo, é o mesmo em todas as páginas que você abrir e serve apenas para agrupar visitas no contador de visitas. Os cookies do Google Analytics só são gravados se você escolher "Aceitar todos" no banner de cookies, e os anúncios do Google AdSense são solicitados como não personalizados até que você faça isso. Você pode mudar a sua escolha a qualquer momento pelo link "Preferências de cookies" no rodapé. Os detalhes estão na página de privacidade.

Sim. Pressione Ctrl+Enter, ou ⌘+Enter no Mac, com o foco no editor. O botão Copiar coloca o resultado na área de transferência e o botão Limpar esvazia o editor. A barra de status abaixo do editor mostra o número de linhas e de caracteres e a linha e a coluna atuais.

Até 20.000 linhas por requisição. Uma entrada maior é recusada com uma mensagem, em vez de ser cortada. Para scripts maiores, divida-os em arquivos de alguns milhares de linhas, o que também facilita a revisão.

Sim. A entrada é dividida nos pontos e vírgulas e cada comando é formatado na ordem, então um script de migration ou um lote de consultas volta com todos os comandos organizados do mesmo jeito.

O formatador foi projetado para mudar apenas espaços em branco, quebras de linha e a caixa das palavras-chave. Literais de string, identificadores entre aspas e comentários ficam como estão, assim como nomes qualificados como t.month. Um ponto de atenção: uma palavra isolada e sem aspas que coincida com uma palavra-chave do SQL tem a caixa alterada, inclusive um nome de coluna ou alias como month, que vira MONTH com palavras-chave em maiúsculas. A maioria dos bancos de dados trata nomes sem aspas sem diferenciar maiúsculas de minúsculas, mas, se o seu não faz isso, qualifique esses nomes ou coloque-os entre aspas. Como em qualquer ferramenta que reescreve código, revise o resultado antes de executá-lo em produção.

Sim. Tanto os comentários de linha -- quanto os comentários de bloco /* */ são preservados na saída, e a caixa do texto deles não é alterada.

São cinco. Espaços de indentação (padrão 4) define a profundidade de cada nível de aninhamento, e os tabs da entrada são substituídos por essa quantidade de espaços, exceto dentro de literais de string e de identificadores entre aspas. Quantidade máxima de colunas (padrão 120; 0 desativa) quebra as linhas que continuam longas demais. Vírgulas coloca as vírgulas depois de um item (o padrão) ou antes do item seguinte. Palavras-chave escreve as palavras-chave em maiúsculas (o padrão) ou em minúsculas. Parênteses em nova linha (desativada por padrão) move o parêntese de abertura de um bloco indentado, como uma subconsulta, para uma linha própria.

É a convenção mais usada em guias de estilo e documentação de SQL. Palavras-chave em maiúsculas separam a estrutura da consulta (SELECT, FROM, WHERE) dos nomes das suas tabelas e colunas, o que ajuda na leitura de um comando longo. Minúsculas funcionam igualmente bem se o seu time preferir; o que importa é ser consistente. O guia de estilo de SQL trata disso e de outras convenções.

A Quantidade máxima de colunas é aplicada numa passada final, depois que o layout está pronto. Qualquer linha maior que o limite é quebrada no último espaço antes dele, e a continuação recebe dois espaços extras de indentação. Ela não reorganiza as cláusulas. Ela nunca quebra dentro de um literal de string, de um identificador entre aspas ou de um comentário e, quando a quebra vem depois de uma vírgula, a vírgula fica no fim da linha. Se uma quebra cair num lugar ruim, aumente o limite ou defina-o como 0 para desativar a quebra.

Não há uma opção de dialeto. As regras de layout funcionam sobre o SQL que os dialetos têm em comum: SELECT, joins, subconsultas, CASE, DML e DDL. O PostgreSQL recebe tratamento extra para casts com ::, parâmetros $1, operadores de JSON e de array e corpos com dollar quoting. Nomes entre crases do MySQL e nomes entre colchetes do SQL Server, como [dbo].[orders], são mantidos inteiros e nunca têm a caixa alterada. Não há tratamento específico para o separador de lotes GO nem para blocos BEGIN … END fora dos dollar quotes do PostgreSQL, então revise esses scripts com mais cuidado. Veja diferenças entre dialetos SQL e o guia de formatação para PostgreSQL.

Funções do PostgreSQL e blocos DO com corpo $$ recebem um layout de PL/pgSQL: DECLARE, BEGIN, IF, ELSIF, LOOP, EXCEPTION e END são organizados como blocos. Corpos de procedures em T-SQL e PL/SQL são formatados como uma sequência de comandos simples, sem um layout de blocos especial.

Use a página de contato. Inclua um pequeno trecho de SQL que mostre o problema, as opções que você usou e o resultado que esperava. Remova quaisquer nomes ou valores confidenciais antes de enviar.