Той идва от оригиналните sql стандарти, които чрез няколко слоя на индиректност в крайна сметка стигат до начало на идентификатор блок, което е едно от няколкото неща, но преди всичко е "обикновена латинска буква". Има и други неща, които могат да се използват, но ако искате да видите всички подробности, отидете на http://en.wikipedia.org/wiki/SQL-92 и следвайте връзките към действителния стандарт (стр. 85)
Наличието на въвеждащи нечислови идентификатори прави писането на синтактичен анализатор за декодиране на sql за изпълнение по-лесно и по-бързо, но формата с цитати също е добре.
Редактиране:Защо е по-лесно за анализатора?
Проблемът за анализатора е повече в SELECT -списък клауза от FROM клауза. Списъкът за избор е списъкът с изрази, които са избрани от таблиците и това е много гъвкаво, позволявайки прости имена на колони и числови изрази. Помислете за следното:
SELECT 2e2 + 3.4 FROM ...
Ако имената на таблици и колоните могат да започват с цифри, е 2e2 име на колона или валиден номер (e форматът обикновено е разрешен в числови литерали) и е 3.4 таблицата "3 " и колона "4 " или това е числовата стойност 3.4 ?
Наличието на правилото, чеидентификатори започнете с прости латински букви (и някои други специфични неща) означава, че синтактичен анализатор, който вижда 2e2 може бързо да разпознае, че това ще бъде числов израз, същото се отнася и за 3.4
Макар че би било възможно да се разработи схема, позволяваща цифрови водещи знаци, това може да доведе до още по-неясни правила (мнение), така че това правило е хубаво решение. Ако първо разрешите цифри, винаги ще има нужда от цитиране, което може би не е толкова „чисто“.
Отказ от отговорност , опростих леко горното, игнорирайки имената на корелация, за да бъда кратък. Не съм напълно запознат с postgres, но проверих два пъти горния отговор спрямо документацията на Oracle RDB и спецификацията на sql
