markieren

SQL-Code:

INSERT INTO ... RETURNING mr_id;
oder?
INSERT INTO ... RETURNING mr_id AS mrID;

markieren

SQL-Code:

INSERT INTO ... VALUES
  (mrID, ...),
  (mrID, ...),
  ...;

Im Prinzip könnte ich ja das erste Insert in das Zweite reinbekommen, aber wie mache ich es, wenn ich den Wert mehrfach benötige? (temporäre Variablen gibt's scheinbar nicht)



Oder kann man vielleicht beim INSERT irgendwie angeben, daß bei jedem Record ein zusätzliches Feld mit diesem Wert gesetzt werden soll?

markieren

SQL-Code:

quasi statt
INSERT INTO t (i, a, b, c) VALUES (mrID, 'a', 'b', 'c'), (mrID, 'a', 'b', 'c')
sowas
INSERT INTO t (a, b, c) VALUES ('a', 'b', 'c'), ('a', 'b', 'c') ÜBERALL i = mrID

Ich habe keine Ahnung von Postgres,
beim MS-SQL-Server ginge es so

markieren

Code:

Insert into Nase ([Spalte 0],[Spalte 1],[Spalte 2])
Select 1,'text1',1.1
union
Select 2,'text2',2.2
union
Select 3,'text3',3.3

Nur kann ich da nicht erkennen, wo der mehrfach verwendete Wert reinkommt?

Für eine Zeile wäre es etwa so.
INSERT INTO t (a, b, c, i) VALUES ('a', 'b', 'c', (INSERT INTO ... RETURNING mr_id)) .
Aber ich möchte die ID ja an mehreren Stellen verwenden.

Ich versteh Dein Problem nicht ganz.
MR_ID müsste doch mit einer der Spaltennamen übereinstimmen und macht m.E. nur Sinn, wenn dieser Wert durch die DB/ Trigger/ Default automatisch belegt wird. Zumindest wenn es ein dynamischer "OUT" Parameter sein soll.
Wenn es bloß eine "IN"-Konstante für mehrere Zeilen ist, kannst Du sie doch explizit in das Statement eintragen.

P.S: Hab auch keine Ahnung von Postgres.

mr_id ist ein AutoInc-Field.

Im Prinzip geht es um sowas:

zusammenfalten · markieren

SQL-Code:

CREATE TABLE Personen (
  Person SERIAL PRIMARY KEY,
  Name VARCHAR(50) NOT NULL);

CREATE TABLE Körperteil (
  Person INTEGER NOT NULL REFERENCES Person ON UPDATE CASCADE,
  Name VARCHAR(50) NOT NULL,
  Größe INTEGER NOT NULL);



pID := INSERT INTO Personen (Name) VALUES ('Frank') RETURNING PersonId;
INSERT INTO Körperteile (Person, Name, Größe) VALUES (:pID, 'Nase', 10), (:pID, 'Mund', 20), (:pID, 'Augen', 5);

-- bzw.
pID := INSERT INTO Personen (Name) VALUES ('Frank') RETURNING PersonId;
INSERT INTO Körperteile (Person, Name, Größe) VALUES (:pID, 'Nase', 10);
INSERT INTO Körperteile (Person, Name, Größe) VALUES (:pID, 'Mund', 20);
INSERT INTO Körperteile (Person, Name, Größe) VALUES (:pID, 'Augen', 5);
...

Nur eben am Ende nur als ein einziges Statement.

Innerhalb von diesen komischen Prozeduren ginge sowas, aber in einer einfachen Query sieht es mit Variablen etwas schlecht aus.

markieren

SQL-Code:

CREATE FUNCTION ... AS #
DECLARE mrID INTEGER;
BEGIN
  SELECT mr_id INTO mrID FROM ...;
  
  INSERT INTO table VALUES (mrID, 'Nase', 10), (mrID, 'Mund', 20);
END#;

Also für jeden Datensatz den automatisch vergebenen Wert? Wenn ich es richtig gelesen habe, kann PostreSQL in Stored Procedures ganze Datenmengen zurückgeben. Wie man da nun aber auch Datenmengen als Eingabeparameter übergeben könnte, weiß ich leider auch nicht.

Zitat von DeddyH:

Also für jeden Datensatz den automatisch vergebenen Wert?

Jupp.

Einen Wert/eine Stelle kann ich ersetzen, aber eben nicht Mehrere.

Also wenn es darum geht, dass Du Dir sparen willst, den Parameter im InsertQueury mehrfach zu bestücken, dann könnte man evtl. so vorgehen:

In Delphi Query SQL anonymous block in psql mit Variablen Declaration erzeugen, Variable einmalig mit Parameter bestücken und abfeuern.

So mach ich das zumindest in Oracle. Postgress soll ja "halbwegs" ähnlich sein. Obs geht weiß ich nicht, auf die Schnelle habe ich sowas hier gefunden:

http://blog.endpoint.com/2010/09/ano...de-blocks.html

Ob es das richtige ist und in Deiner Postgres Version auch geht, musst Du schauen.

Cool, das mit dem Anonymus funktioniert.

markieren

SQL-Code:

DO $$
DECLARE mrID INTEGER;
BEGIN
  
END$$;

Ich hatte es schon mit einer ähnlichen (krankeren) Variante versucht.
> StroredProzedur erstellen, aufrufen und wieder löschen
Nur ist das nicht grade "schön".

Fein!

Gegen eine StoredProc spricht ja eigentlich auch nichts, ich mein, wenn man sie nicht ständig erzeugt und wieder löscht.

Aber ich glaub, ich muss mir postgres auch mal anschauen.
Wenn sowas geht, gefällt mir das doch erst recht.

Und krank find ich jetzt anonymous block nicht grad. Wenn man unbedingt keine stored procs nutzen will, ist es doch ne schöne Alternative.