Problem mit Prepared Statement bei Postgres

[Alexander (HH)]

Moin Moin!

Hallo Alexander,

danke für deine Hilfe.

Am Rande: Woher hast Du eigentlich die merkwürdige Idee, alle Identifier quoten zu müssen?

nun deswegen drehe ich mich schon eine Weile im Kreis. Ich hatte von MySQL zu Postgres migriert. Vorher hatte in MySQl dies wunderbar funktioniert.

Es funktioniert noch viel besser, wenn Du dich bei den Identifiern auf das Set [A-Za-z0-9_] beschränkst und auf die Quotes verzichtest. Dann ist SQL nämlich case insensitiv.

Dies ist aber auch nur eine Lösung. Das Problem ist nun nämlich das man z.b. bei Returnwerten einer Funktion auch alles klein schreiben muss.

vorher:
return $foundroot['MyDirectoryPath'];

mus ich nun ändern in;
return $foundroot['mydirectorypath'];

Das ist zur Hälfte eine Macke von PostgreSQL, dessen Identifier sind im Gegensatz zu den meisten anderen RDBMS intern als Kleinbuchstaben statt als Großbuchstaben abgelegt und auch an der Schnittstelle so wieder ausgibt.

Die andere Hälfte des Problems ist, dass Du PDO::CASE_XXX offenbar nicht kennst. (Am Rande: Perls DBI nennt das FetchHashKeyName.) Damit bekommst Du DB-unabhängig immer Bit für Bit die selben Spaltennamen.

Du siehst ich drehe mich immer noch im Kreis. Wie dedlfix und auch Vinzenz schön öfters gesagt haben. Einheitlichen Code DB übergreifend hinzubekommen ist vermutlich eine Illusion.

Nein, nur ein fehlender Layer zwischen DB-Schnittstelle und Programm.

Ich hab mit ein paar hundert Zeilen Perl, aufsetzend auf DBI, schon im letzten Jahrhundert DB-unabhängigen Code geschrieben. Das Programm lief (und läuft noch heute) ohne eine Zeile Code zu ändern auf diversen Versionen von Oracle, MS SQL Server und PostgreSQL; DB2-Support war geplant, MySQL (3 und 4) wegen der diversen Macken explizit ausgeschlossen. Prinzipiell müßte das System auch mit SQLite und anderen RDBMS funktionieren.

Natürlich muß man sich dabei ein wenig einschränken, was Features angeht. Man kann nicht einfach irgendein MySQL-Script in Oracle stopfen und hoffen, dass Oracle das ohne Murren verdaut. Mein Layer hat sich damals hauptsächlich um Meta-Informationen (welche Tabellen gibt es, welche Spalten haben sie), Datentypen-Mapping ("STRING:255" heißt in Oracle VARCHAR2(255), in MSSQL "NVARCHAR(255)" und in PostgreSQL "VARCHAR(255)") und Insert-Statements gekümmert, der Rest ging ohne Mehraufwand direkt durch zum DBI.

Heute würde ich vermutlich einen ORM zwischen Anwendung und DB-Schnittstelle setzen, damit spare ich mir für Routine-Fälle das SQL komplett, weil es stumpf automatisch generiert wird, sobald der ORM über die darunter liegende DB informiert ist.

Alexander