Alexander (HH): Problem mit Prepared Statement bei Postgres

Beitrag lesen

Moin Moin!

Hallo Alexander,

Ungequoted aus dem Set [A-Z0-9_], sowohl für Spalten als auch für andere Identifier (Namen von Tabellen, Views, Prozeduren, Funktionen, Variablen, ...).

OK, das würde ja auch meiner bisherigen Schreibweise entsprechen.

LANGUAGE_ID, Language_ID, language_id, wie es Dir gerade paßt. Ist alles beliebig, so lange Du die Finger von den Quotes läßt.

Ok, stellt sich mir nun nochmals die Frage. Ist dann dein SQL Code identisch zur DB.

Hä?

Wenn du also z.b. eine PHP Datei hast wo etwa:
SELECT LanguageID FROM mytable WHERE UserID = 3
steht. Ist dann auch in deiner DB die Spaltenbezeichnung in dieser Schreibweise?

Ich lege Tabellen- und Spaltennamen an, ohne Quoting zu benutzen. Wie die DB das intern speichert, ist mir völlig egal.

Ich benutze Tabellen- und Spaltennamen in SQL-Statements ohne Quoting, wie die DB damit intern arbeitet, ist mir völlig egal.

In Fetches kümmert sich DBI darum, dass die Spaltennamen in eine von der DB unabhängige Schreibweise umgesetzt werden, je nach Projektalter und Tageslaune beim Anlegen des Projekts mal Kleinbuchstaben, mal Großbuchstaben. PDO sollte das über die CASE-Konstanten ebenfalls können.

Wenn ja bin ich wieder bei dem alten Problem, siehe;

https://forum.selfhtml.org/?t=203232&m=1374036

Wo ist da nur das Problem? Einmal Editor-Kommando "search and replace in files" für alle Projektdateien pro Spaltenname, fertig. Notfalls klappt das auch mit find, xargs und sed.

Bei MySQL kann ich ja problemlos meine Spalten in Groß-Kleinschreibweise anlegen.

Das kannst Du auch in vielen anderen RDBMS.

Postgres macht mir hier aber automatisch um jeder Spalte diese Hochkommas.

Hä? Wo erzeugt PostgreSQL Single Quotes?

Ich habe bis jetzt zumindest keine Möglichkeit gefunden eine Spalte in PG z.b. LanguageID zu bezeichnen, ohne Hochkommas

Identifiers and Key Words

Pack Identifier in Double Quotes und PostgreSQL erlaubt Dir fast jeden Unfug als Identifier zu benutzen: "Quoted identifiers can contain any character, except the character with code zero. (To include a double quote, write two double quotes.) This allows constructing table or column names that would otherwise not be possible, such as ones containing spaces or ampersands. The length limitation still applies." Du kannst sogar beliebige Zeichen aus Unicode herauspicken, solltest Du Deine Spalten mal in Kanji, Kyrillisch oder Arabisch benennen wollen.

Ohne Double Quotes gelten die Regeln für einfache Identifier: "SQL identifiers and key words must begin with a letter (a-z, but also letters with diacritical marks and non-Latin letters) or an underscore (_). Subsequent characters in an identifier or key word can be letters, underscores, digits (0-9), or dollar signs ($). Note that dollar signs are not allowed in identifiers according to the letter of the SQL standard, so their use might render applications less portable. The SQL standard will not define a key word that contains digits or starts or ends with an underscore, so identifiers of this form are safe against possible conflict with future extensions of the standard. [...] Key words and unquoted identifiers are case insensitive."

In Sachen Wartbarkeit habe ich Dir ja bereits geraten, Dich auf einfache Identifier zu beschränken, vergiß also am besten, dass es Quoted Identifiers überhaupt gibt.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".