Tabelle oder Spalte name kann nicht starten mit numerischen?

Habe ich versucht zu erstellen Tabelle mit dem Namen 15909434_user mit syntax wie folgt:

CREATE TABLE 15909434_user ( ... )

Würde es produziert Fehler natürlich. Dann, nachdem ich versucht habe ein bisschen recherche mit google fand ich einen guten Artikel hier beschreiben:

Wenn Sie ein Objekt erstellen, das in PostgreSQL, geben Sie diesem Objekt einen Namen. Jede Tabelle hat einen Namen, jede Spalte hat einen Namen, und so weiter. PostgreSQL verwendet einen einzigen Datentyp zu definieren, der alle Objektnamen: die name geben.

Einen Wert vom Typ name ist eine Zeichenfolge von 63 oder weniger Zeichen. Ein name beginnt mit einem Buchstaben oder einem Unterstrich beginnen; der rest der Zeichenkette kann Buchstaben, Ziffern und Unterstriche.

...

Wenn Sie feststellen, dass Sie brauchen, um ein Objekt zu erstellen, die nicht erfüllen diese Regeln, können Sie setzen Sie den Namen in doppelte Anführungszeichen. Wickeln Sie einen Namen in Anführungszeichen, erzeugt einen Bezeichner. Zum Beispiel könnten Sie eine Tabelle erstellen, deren name "3.14159"—die Anführungszeichen sind notwendig, aber sind nicht tatsächlich ein Teil des namens (das heißt, Sie werden nicht gespeichert und zählen nicht gegen den 63-Zeichen-Grenze). ...

Okay, jetzt weiß ich, wie man dieses Problem lösen, indem Sie die folgende syntax verwenden (double quote on table name):

CREATE TABLE "15909434_user" ( ... )

Können Sie erstellen, Tabellen-oder Spaltenname, wie "15909434_user" und auch user_15909434, aber nicht erstellen Tabelle oder Spalte name beginnt mit numerischen und ohne die Verwendung von doppelten Anführungszeichen.

Also dann, bin ich neugierig über den Grund hinter, dass (außer es ist eine Konvention). Warum dieses übereinkommen angewendet? Ist es zu vermeiden, so etwas wie syntax Verjährung oder einem anderen Grund?

Dank im Voraus für Ihre Aufmerksamkeit!

InformationsquelleAutor Wayan Wiprayoga | 2013-04-10

  1. 19

    Kommt es aus der ursprünglichen sql-standards, die durch mehrere Ebenen der Dereferenzierung irgendwann ein Bezeichner beginnen block, das ist eines der vielen Dinge, aber in Erster Linie ist es "einen einfachen lateinischen Buchstaben". Es gibt auch andere Dinge, die verwendet werden können, aber wenn Sie wollen, um zu sehen, alle details, gehen Sie zu http://en.wikipedia.org/wiki/SQL-92 und Folgen Sie den links, um die aktuelle standard - ( Seite 85 )

    Dass nicht numerische Kennung Vermittler macht das schreiben eines parser zu entschlüsseln sql für die Ausführung einfacher und schneller, aber eine zitierte form ist auch in Ordnung.

    Edit: Warum ist es einfacher für den parser?

    Das problem für einen parser ist mehr in der SELECT-list-Klausel als die FROM - Klausel. Die select-Liste ist die Liste der Ausdrücke, die ausgewählt sind aus den Tabellen, und diese ist sehr flexibel, ermöglicht einfachen Spaltennamen und numerische Ausdrücke. Betrachten Sie das folgende:

    SELECT 2e2 + 3.4 FROM ...

    Wenn Tabellennamen und Spaltennamen beginnen konnte, mit Numerik, ist 2e2 eine Spalte mit Namen oder eine gültige Zahl (e- format ist in der Regel erlaubt bei numerischen literalen) und ist 3.4 die Tabelle "3" und Spalte "4" oder ist es der numerische Wert 3.4 ?

    Haben die Regel, dass Bezeichner beginnen Sie mit einfachen lateinischen Buchstaben (und einigen anderen speziellen Dingen) bedeutet, dass ein parser, der sieht 2e2 können schnell erkennen, das wird ein numerischer Ausdruck, der gleiche deal mit 3.4

    Zwar wäre es möglich, die Entwicklung einer Regelung zu ermöglichen, numerische führenden Zeichen, dies könnte führen zu noch mehr obskure Regeln (Meinung), so ist diese Regel eine schöne Lösung. Wenn Sie erlaubt haben, Ziffern, die ersten, dann würde es immer brauchen zitieren, die wohl nicht als 'sauber'.

    Haftungsausschluss, ich habe vereinfacht, die oben etwas, ignorieren corelation Namen, es kurz zu halten. Ich bin nicht völlig vertraut mit postgres, aber doppelt geprüft habe die obige Antwort gegen Oracle RDB-Dokumentation und sql-spec

    Ich bin noch Anfänger, wie mit postgreSQL-parser arbeiten, ich bin wieder neugierig darüber, warum Decodierung Bezeichner wie "123456_name" oder name_123456 ist einfacher und schneller als 123456_name?

    InformationsquelleAutor rlb

  2. 6

    Ich würde vorstellen, es ist zu tun mit der Grammatik.

    SELECT 24*DAY_NUMBER as X from MY_TABLE

    ist in Ordnung, aber mehrdeutig, wenn 24 wurde erlaubt, den Namen einer Spalte.

    Hinzufügen von Anführungszeichen bedeutet, Sie sind explizit unter Bezugnahme auf eine Kennung nicht konstant. Also, um es zu benutzen, würde Sie immer haben, um es zu entkommen sowieso.

    Genau, es ist zur Verringerung Mehrdeutigkeit in der Analyse. Es hilft nicht, dass im PostgreSQL-parser quirk bedeutet, dass SELECT 123abcd wird interpretiert als SELECT 123 AS abcd, dh auch ohne Leerzeichen den string nach den zahlen wird als eine Spalte alias.
    Okay, habe es Ihre Idee. Aber es ist, weil Sie beinhalten operator-syntax gibt. Wie über die Verwendung von nicht-operator syntax wie SELECT 24_DAY_NUMBER as X FROM MY_TABLE es sollte nicht mehrdeutig.
    für SELECT 123abcd wird interpretiert als SELECT 123 AS abcd. Ich noch immer fehlt das Konzept der Mehrdeutigkeit in der SQL-syntax-Analyse verwendet. Warum CREATE TABLE 15909434_user mehrdeutig ist mit CREATE TABLE user_15909434. Sorry für die blöde Frage.. 😉
    Zwingen Bezeichner beginnen mit einer Nummer können die parser einfacher und Fehler früher. Der standard spezifiziert ist, so dass PostgreSQL nicht wirklich frei, es trotzdem zu ändern. Es ist detail; nehmen Sie es als gegeben, dass dies ist, wie es ist, wenn Sie wirklich interessiert in den Eingeweiden der recursive-descent-Parser.
    Okay, ich denke, wenn wir weiterhin die Diskussion über den parser, es wäre off-topic hier. @CraigRinger könnten Sie beantworten diese Frage mit Ihrer Idee. Oder verbessern Sie diese Antwort mit der Ergänzung deiner Vorstellung. Ich möchte annehmen, diese Diskussion, da die Antwort.. 🙂

    InformationsquelleAutor LoztInSpace

Schreibe einen Kommentar