Потоковое с Amazon S3

Он исходит из исходных стандартов sql, которые через несколько слоев косвенности в конечном итоге попадают в стартовый блок идентификатора, что является одной из нескольких вещей, но в первую очередь это «простая латинская буква». Есть и другие вещи, которые можно использовать, но если вы хотите просмотреть все подробности, перейдите к http://en.wikipedia.org/wiki/SQL-92 и следуйте ссылкам на фактический стандарт (стр. 85)

Наличие носителей, не содержащих числовой идентификатор, делает запись синтаксического анализатора для более простого и быстрого декодирования sql для выполнения, но кавычка тоже прекрасна.

Edit : Почему для парсера проще?

Проблема для синтаксического анализа больше в предложении SELECT -list, чем в предложении FROM. Список выбора - это список выражений, выбранных из таблиц, и это очень гибко, что позволяет использовать простые имена столбцов и числовые выражения. Рассмотрим следующее:

SELECT 2e2 + 3.4 FROM ...

Если имена таблиц и имена столбцов могут начинаться с числовых значений, это 2e2, имя столбца или допустимое число (e формат обычно разрешается в числовых литералах) и является 3.4 таблицей «3» и столбцом «4» или это числовое значение 3.4?

Имея правило, что идентификаторы начинаются с простых латинских букв (и некоторых других конкретных вещи) означает, что синтаксический анализатор, который видит 2e2, может быстро распознать это, будет числовым выражением, то же самое касается 3.4

. Хотя можно было бы разработать схему, позволяющую содержать числовые ведущие символы, это может привести к еще более неясным правилам (мнению), поэтому это правило является хорошим решением. Если вы разрешили сначала цифры, тогда ему всегда нужно было бы цитировать, что, возможно, не было «чистым».

Отказ от ответственности, я немного упростил приведенное выше, игнорируя имена исправлений, чтобы сохранить это коротко. Я не полностью знаком с postgres, но дважды проверил вышеприведенный ответ на документацию Oracle RDB и sql spec

blockquote>