Re: t=?ISO-8859-1?Q?ats=E4chlich_(k?=)ein Syntaxfehler

From: "Christoph 'Le=?ISO-8859-1?Q?o'_Wei=DFenborn?=" <chw-le(at)gmx(dot)de>
To: Andreas Seltenreich <andreas+pg(at)gate450(dot)dyndns(dot)org>
Cc: pgsql-de-allgemein(at)postgresql(dot)org
Subject: Re: t=?ISO-8859-1?Q?ats=E4chlich_(k?=)ein Syntaxfehler
Date: 2005-08-04 07:33:11
Message-ID: 1123140791.42f1c4b777cda@mail.uni-leipzig.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-de-allgemein

Hallo Andreas,

erstmal ein Dank! Besonders der Hinweis auf PREPARE ... hilft mir
was weiter. Aber:

Zitiere Andreas Seltenreich <andreas+pg(at)gate450(dot)dyndns(dot)org>:
> Christoph Weißenborn schrob:
> [...]
> > String q3 = "CREATE USER ?";
> > stmt3 = con.prepareStatement(q3);
> [...]
>
> Das schlägt aus dem gleichen Grund fehl, wie ein
> PREPARE foo (name) AS CREATE USER $1;
> Oder ein
> PREPARE foo (name) AS SELECT * FROM $1;
>
> Der Planner kann ohne zugrundeliegende Relation seine Arbeit nicht
> machen. Kein Plan, kein prepared Statement. Also bei den
> Utility-Funktionen Finger weg von den prepared Statements.

Da ich mit PostGres noch nicht so vertraut bin, sagt mir das leider
noch nicht viel. Ich verstehe das mal so: ohne Tabelle kann der
Planer nix vorbereiten. Aber dann frage ich mich, wie die Benutzer
verwaltet werden? Nicht auch in einer Tabelle?
Und was sind Utility-Funktionen? (Die ohne Tabellenzugriff? Also
alles außer: SELECT/INSERT/UPDATE/DELETE FROM ?!)

Ich habe nach einigem Probieren auch mal den JDBC-Treiber 7.4
probiert. Mit dem klappt zumindest:
CREATE USER "bibo2" WITH UNENCRYPTED PASSWORD $1
Warum geht dies nun aber mit dem 8.0 nicht mehr?

Laut JDBC-Spek _kann_ ein PreparedStatement vorbereitet werden. Ist
dies jedoch nicht möglich (was bei CREATE USER $1) wohl der Fall
ist, so muß der Treiber nicht zwangsläufig in einen Fehler laufen.
Er müßte dann eigentlich selbst die Parameter einsetzen und das
komplette Query dann übermitteln ohne Vorbereitung und somit ohne
Optimierung. In der JDBC-Spek ist jedenfalls nicht davon die Rede,
daß bestimmte Queries nicht als PreparedStatement ausgeführt werden
können sollen.²
Für den Nutzer von JDBC ist ein Hauptvorteil, daß Parameter nicht
"escaped" werden müssen. Schließlich ist dies bei jeder DB-Engine
anders zu tun. Erst bei vielen 100 oder 1000 gleich strukturierten
Queries greift eine Optimierung für PreparedStatements (imo).

² Das klingt etwas angriffslustig, so ist es nicht gemeint. Wenn es
nicht geht möchte ich nur gern verstehen, warum das nicht gehen kann.
Nur so vermeide ich weitere Fehler.

Gruß,
Christoph
--
Fingerprint=65B7 73B6 5969 AC2B 4572 39A2 0DBC DAC1 3D6A 45B7

In response to

Responses

Browse pgsql-de-allgemein by date

  From Date Subject
Next Message Peter Eisentraut 2005-08-04 08:31:33 Re: tatsächlich (k)ein Syntaxfehler
Previous Message Andreas Kretschmer 2005-08-04 05:14:28 Re: [despammed] Welche GUI ist empfehlenswert ?