Имя таблицы или столбца не может начинаться с numeric?

Я попытался создать таблицу с именем 15909434_user синтаксис, как показано ниже:

CREATE TABLE 15909434_user ( ... )

это привело бы к ошибке, конечно. Затем, после того, как я попытался провести небольшое исследование с google, я нашел хорошую статью здесь, которые описывают:

когда вы создаете объект в PostgreSQL, вы даете этому объекту имя. Каждая таблица имеет имя, каждый столбец имеет имя, и так далее. PostgreSQL использует один тип данных для определения всех имен объектов:name тип.

значение типа name - это строка 63 символов. Имя должно начинаться с буквы или подчеркивания; остальная часть строки может содержать буквы, цифры и подчеркивания.

...

если вы обнаружите, что вам нужно создать объект, который не соответствует этим правилам, вы можете заключить имя в двойные кавычки. Обертывание имени в кавычки создает идентификатор кавычки. Например, можно создать таблицу с именем "3.14159"-двойные кавычки обязательны, но на самом деле не являются частью имени (то есть они не сохраняются и не учитываются в 63-символьном пределе). ...

хорошо, теперь я знаю, как это решить, используя этот синтаксис (ставя двойную кавычку на имя таблицы):

CREATE TABLE "15909434_user" ( ... )

вы можете создать имя таблицы или столбца, например "15909434_user" и user_15909434, но не может создать имя таблицы или столбца, начинающееся с числового без использования двойных кавычек.

так тогда мне любопытно узнать причину этого (за исключением того, что это конвенция). Почему применяется эта конвенция? Это чтобы избежать чего-то вроде ограничения синтаксиса или другой причины?

заранее спасибо за внимание!

12
naming-conventions postgresql sql

2 ответов

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

С не числовым идентификатором introducers делает написание парсера для декодирования sql для выполнения проще и быстрее, но цитируемая форма тоже прекрасна.

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

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

SELECT 2e2 + 3.4 FROM ...

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

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

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

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

18

Я бы предположил, что это связано с грамматикой.

SELECT 24*DAY_NUMBER as X from MY_TABLE

отлично, но неоднозначно, если в качестве имени столбца было разрешено 24.

добавление кавычек означает, что вы явно ссылаетесь на идентификатор, а не константу. Поэтому, чтобы использовать его, вам все равно придется избегать его.

6