Pochodzi z oryginalnych standardów sql, które poprzez kilka warstw pośrednich ostatecznie docierają do początku identyfikatora blok, który jest jedną z kilku rzeczy, ale przede wszystkim jest „prostą literą łacińską”. Są też inne rzeczy, których można użyć, ale jeśli chcesz zobaczyć wszystkie szczegóły, wejdź na http://en.wikipedia.org/wiki/SQL-92 i skorzystaj z linków do aktualnego standardu ( strona 85 )
Posiadanie nienumerycznych programów wprowadzających identyfikatory sprawia, że pisanie parsera do dekodowania sql w celu wykonania jest łatwiejsze i szybsze, ale forma cytowana też jest w porządku.
Edytuj:dlaczego jest to łatwiejsze dla parsera?
Problem parsera jest bardziej w SELECT -list klauzula niż FROM klauzula. Lista wyboru to lista wyrażeń wybieranych z tabel, która jest bardzo elastyczna, umożliwiając proste nazwy kolumn i wyrażenia numeryczne. Rozważ następujące kwestie:
SELECT 2e2 + 3.4 FROM ...
Jeśli nazwy tabel i nazwy kolumn mogą zaczynać się od cyfr, to 2e2 nazwa kolumny lub poprawny numer (e format jest zazwyczaj dozwolony w literałach numerycznych) i to 3.4 tabela „3 " i kolumna "4 " czy jest to wartość liczbowa 3.4 ?
Mając zasadę, że identyfikatory zacząć od prostych liter łacińskich (i kilku innych specyficznych rzeczy) oznacza, że parser, który widzi 2e2 może szybko rozpoznać, że będzie to wyrażenie numeryczne, to samo dotyczy 3.4
Chociaż byłoby możliwe wymyślenie schematu, który umożliwiłby wprowadzenie wiodących znaków numerycznych, może to prowadzić do jeszcze bardziej niejasnych zasad (opinii), więc ta zasada jest dobrym rozwiązaniem. Jeśli najpierw zezwolisz na cyfry, zawsze będzie to wymagało cytowania, co prawdopodobnie nie jest tak „czyste”.
Zastrzeżenie , nieco uprościłem powyższe, ignorując nazwy korelacji, aby były krótkie. Nie jestem do końca zaznajomiony z postgresem, ale dwukrotnie sprawdziłem powyższą odpowiedź z dokumentacją Oracle RDB i specyfikacją sql
