Я пытался создать таблицу с именем 15909434_user
с синтаксисом как ниже:
CREATE TABLE 15909434_user ( ... )
Это произвело бы ошибку конечно. Затем, после того, как я попытался немного изучить Google, я нашел хорошую статью Вот которые описывают:
Когда вы создаете объект в PostgreSQL, вы даете этому объекту имя. У каждой таблицы есть имя, у каждого столбца есть имя и так далее. PostgreSQL использует один тип данных для определения всех имен объектов:
name
тип.Значение типа
name
это строка из 63 или менее символов. Имя должно начинаться с буквы или символа подчеркивания; остальная часть строки может содержать буквы, цифры и символы подчеркивания.…
Если вы обнаружите, что вам нужно создать объект, который не соответствует этим правилам, вы можете заключить имя в двойные кавычки. Заключение имени в кавычки создает заключенный в кавычки идентификатор. Например, вы можете создать таблицу с именем «
3.14159
«- двойные кавычки обязательны, но на самом деле не являются частью имени (то есть они не сохраняются и не считаются с ограничением в 63 символа) …
Хорошо, теперь я знаю, как решить эту проблему, используя этот синтаксис (помещая двойные кавычки в имя таблицы):
CREATE TABLE "15909434_user" ( ... )
Вы можете создать имя таблицы или столбца, например "15909434_user"
а также user_15909434
, но не может создать имя таблицы или столбца, начинающееся с цифры, без использования двойных кавычек.
Итак, мне интересно узнать причину этого (за исключением соглашения). Почему эта конвенция применяется? Это чтобы избежать чего-то вроде ограничения синтаксиса или другой причины?
Заранее спасибо за внимание!
Это происходит от оригинальных стандартов 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
Я предполагаю, что это связано с грамматикой.
SELECT 24*DAY_NUMBER as X from MY_TABLE
это хорошо, но неоднозначно, если 24 было разрешено в качестве имени столбца.
Добавление кавычек означает, что вы явно ссылаетесь на идентификатор, а не на константу. Таким образом, чтобы использовать его, вам все равно придется избежать его.