Formatowanie SQL

Ten formater dopasowuje słowa kluczowe, więc rozbije ciąg znaków zawierający słowo FROM

Dzieli zapytanie po białych znakach i interpunkcji, a przed każdym z dwudziestu trzech słów kluczowych wstawia łamanie wiersza. Nie ma pojęcia, czym jest literał tekstowy. Sformatuj SELECT name FROM t WHERE label = 'order from stock', a literał wróci jako 'order\nfrom stock' — z nową linią wewnątrz cudzysłowów i zapytaniem, które dopasowuje już coś innego.

Jak to działa

• Zwija wszystkie ciągi białych znaków, a potem dzieli zapytanie na tokeny po spacjach, nawiasach, przecinkach i średnikach.
• Zaczyna nowy wiersz przed każdym z dwudziestu trzech słów kluczowych klauzul, dopasowując bez rozróżniania wielkości liter.
• Śledzi zagnieżdżenie po nawiasach otwierających i zamykających, wcinając po dwie spacje na poziom.

dla każdego tokenu:
  jeśli token to ')'  → wcięcie = max(0; wcięcie − 1)
  jeśli token to słowo kluczowe klauzuli → wypisz nową linię + dwie spacje × wcięcie
  wypisz token bez zmian
  jeśli token to '('  → wcięcie = wcięcie + 1

Przykład z liczbami

Zapytanie, którego tekst zawiera słowo kluczowe wewnątrz cudzysłowów.

1. wejście: SELECT name FROM t WHERE label = 'order from stock'
2. SELECT, FROM i WHERE zaczynają nowe wiersze, zgodnie z zamierzeniem
3. słowo from wewnątrz cudzysłowów też zostaje dopasowane, bo cudzysłowy są dla dopasowywacza niewidoczne
4. wynik wstawia łamanie wiersza między 'order a from stock'
5. literał nie jest już tym samym ciągiem znaków co wcześniej

Trzy zamierzone łamania wiersza i jedno, które zmienia znaczenie zapytania. Wszystko poza literałami tekstowymi formatuje się poprawnie; wszystko wewnątrz nich jest zagrożone.

Jak czytać wynik

• Sprawdź każde zapytanie zawierające tekst w cudzysłowach, zanim użyjesz wyniku. Komentarze niosą to samo ryzyko — słowo kluczowe w komentarzu też dostaje łamanie wiersza, a w komentarzu jednoliniowym takie łamanie potrafi zepchnąć resztę komentarza do działającego wiersza SQL.
• Wcięcia podążają wyłącznie za nawiasami, więc odzwierciedlają głębokość zagnieżdżenia, a nie strukturę klauzul. Długie płaskie zapytanie bez nawiasów wychodzi całkowicie bez wcięć, niezależnie od liczby klauzul — dla tej reguły to zachowanie poprawne i często nie to, o które chodziło.
• Lista słów kluczowych jest stała i ogólna. Składnia specyficzna dla dialektu — funkcje okna, wspólne wyrażenia tablicowe, rozszerzenia producenta, MERGE — nie znajduje się na liście i zostanie w wierszu, zamiast dostać własny.
• Dodawane są wyłącznie białe znaki. Tokeny wypisuje się dokładnie tak, jak je wpisałeś, więc twoja wielkość liter zostaje zachowana i żadne słowo kluczowe nie jest przepisywane; narzędzie zmienia układ, a nie tekst.

Częste pytania

Czy można to bezpiecznie uruchamiać na zapytaniach produkcyjnych?

Najpierw sformatuj, a potem przeczytaj wynik przed użyciem. Narzędzie nigdy nie przepisuje twoich tokenów, ale potrafi wstawić nową linię wewnątrz ciągu w cudzysłowach albo komentarza, a w obu przypadkach powstały SQL znaczy co innego niż to, co wkleiłeś.

Dlaczego moje zagnieżdżone zapytanie nie ma wcięcia?

Wcięcia wynikają wyłącznie z nawiasów. Podzapytanie ujęte w nawiasy dostanie wcięcie; ciąg złączeń i klauzul bez nawiasów już nie, bo narzędzie nie ma modelu struktury klauzul, względem którego mogłoby wcinać.