Umstellung PG9 nach PG10

Hallo Wissende,
ich habe umfangreiche (fremde) SQL-Anweisungen (ca. 10000 Zeilen) für PG9.
Ich wollte das Ganze jetzt unter PG10 laufen lassen und bekomme Fehler bei Konstruktionen in der Art

SELECT
  CASE WHEN f1=1103 THEN
      unnest(ARRAY[1000,2000])
  END AS line
FROM meinetabelle

Problem ist das unnest(), welches in dieser Form an vielen Stellen vorkommt

Funktionen mit Ergebnismenge sind in CASE nicht erlaubt

Gibt es eine Möglichkeit den SQL-Code zu “konvertieren”, also ein Umbau ohne sich in die Logik des SQL-Code einarbeiten zu müssen?
Effektivität/Geschwindigkeit sind zweitrangig.

Gruß Steffen

Sinnvoll wäre es schon das zu verstehen und das unnest() in’s FROM zu verschieben.
Ein hässlicher workaround wäre sowas:

SELECT unnest(case when f1 = 1103 then ARRAY[1000,2000] else array[null::int] end) as line
FROM meinetabelle

Das unnest also auf das Ergebnis des CASE anwenden.

Langfristig sollte das unnest aber in’s FROM wandern - da wo alle “Tabellen” hingehören

Ich habe nie verstanden warum Postgres die Verwendung von set returning functions im SELECT zulässt.
Kein Mensch würde auf die Idee kommen sowas zu schreiben:

select t.c1, select * from other_table, t.c2
from the_table t

Was letztendlich die gleiche Semantik ist wie eine set-returning-function dort zu verwenden.

Hallo,
vielen Dank für die schnelle Antwort.
Leider ist selbst so eine “hässliche” Variante nur schwerlich automatisiert auf 10.000 Zeilen Code anzuwenden. Auch scheint das unnest() nicht das einzige Problem zu sein.
Hatte die Hoffnung dass es eine Art Konverter oder eine Kompatibilitätsoption gibt.

Da muss ich mich wohl mittelfristig nach einer anderen Lösung umschauen :frowning: .

Gruß Steffen

Warum eigentlich Postgres 10 wenn es schon 11 und 12 gibt?

Hallo,

Warum eigentlich Postgres 10 wenn es schon 11 und 12 gibt?

Da bin ich von Fremdfirma abhängig.
… ja und ehrlich gesagt. Die fehlende Abwärtskompatibilität von PostgreSQL hat dann doch enttäuscht. Das gab es beim viel gescholtenen MSAccess noch nicht (auch wenn das nur eine Desktop-DB ist) :frowning: .

Gruß Steffen

Hallo,

So, ich hoffe, das kommt nicht negativ rüber.

Mit Sicherheit nicht. In einem PostgreSQL-Forum über PG zu schimpfen und gleichzeitig Access zu loben da macht man sich keine Freunde :slight_smile: .


Ich bin seit mindestens einer Dekade nicht mehr mit Access Entwicklung in Berührung gekommen, aber was man spätestens aus den Anläufen zu Office 365 hört, kann man nicht kompatibel nennen.

Also ich musste von AC97 bis AC2016 noch nie eine Datenbank/einen Code umbauen und Access ist nicht nur eine DB sondern auch ein Frontend. Ausnahme die Entfernung des Rechtesystems ab AC2007.

… dauerhafte Kompatibilität nimmt den Raum für bedeutende Designänderungen.

Da gebe ich dir absolut recht. Aber für mich als Gelegenheitsanwender ist es aber zunächst ziemlich “unschön”.

Ansonsten die konzeptionellen Fehler habe ich nicht zu verantworten ich bin in dem Fall nur Anwender nicht der Programmierer :slight_smile: .

Gruß Steffen

Das Postgres Entwicklungsteam stellt neben der Sicherheit der Daten, Rückwärtskompatibilität an eine der ersten Stellen bei der Entwicklung. Wenn es zwei technisch gleichwertige Lösungen gibt, welche die gleiche Performance haben, wird sicherlich die gewählt, welche bestehenden Code nicht beeinflusst.

Manchmal ist das aber leider nicht möglich und das Verhalten von SRFs (“Set Returning Functions”) war nie wirklich befriedigend. Die Entscheidung an dieser Stelle alte Zöpfe abzuschneiden ist sehr bewusst gefallen. Ich kann mich seit der Version 8.0 (aus 2005) an nur zwei wirklich einschneidende Änderungen erinnern: die Änderungen des Verhaltens von impliziten “casts” und eben das Verhalten von SRFs in der SELECT Liste.

Natürlich ist es ärgerlich wenn so was passiert - ich kann Deinen Frust gut verstehen, aber der Vergleich zwischen Access und Postgres hinkt ein wenig.

Postgres is ungleich viel komplexer (und leistungsfähiger) als der Datenbankkern von MS Access. Ich kann mir auch nicht vorstellen, dass in MS Access (dem Datenbankkern, nicht dem GUI) in den letzten 15 Jahren so viele grundlegende Veränderungen und Erweiterungen eingeflossen sind. Würde MS Access SRFs unterstützen kann ich mir nicht vorstellen, dass die Verwendung in der SELECT Liste überhaupt unterstützt würde (mir ist keine andere Datenbank bekannt, die SRFs unterstützt und diese in der SELECT Liste zulässt - vielleicht war das von Anfang an eine falsche Entscheidung vom Postgres Team).

Wenn man bedenkt, wie viele grundlegende architektonische Änderungen in der Zeit entwickelt wurden (zwei Varianten der Replikation, Parallele Queries, massiver Umbau der Art wie Daten gespeichert werden, Indexstrukturen usw.) dann finde ich das schon ziemlich beeindruckend. Bei Oracle muss man teilweise selbst bei Minor Releases darum bangen, dass die Abfragen immer noch die gleichen Ergebnisse liefern. Ich habe mehrere Projekte die wir von 9.2 bis hin zu 12 migriert haben ohne auch nur einmal ein Problem gehabt zu haben. Bei einer Migration von Oracle 12.2.0.1 zu 12.2.0.3 gab es tatsächlich Abfragen die (bei gleichen Daten) komplett andere (falsche) Resultate geliefert haben, weil der Optimizer Amok gelaufen ist.

Hallo,

Natürlich ist es ärgerlich wenn so was passiert

… ja und mehr wollte ich damit auch nicht ausdrücken :slight_smile: .

… und es war auch für mich auch die Entschuldigung/Ausrede nicht die neusten Versionen einer Software einzusetzen.

Gruß Steffen

Umstellung: Ich hätte da auch noch eine Frage habe PG10 wollte PG11, aber in den Sripts von PG11 funktioniert meine Rechte Mausttaste nur noch in Verbindung mit der Sift-Taste ist das jetzt so geändert oder hab ich bei der Installation etwas übersehen

Postgres selber hat keine Unterstützung für irgendwelche Maustasten (das ist ein Server Prozess ohne sichtbare GUI).

Welchen SQL Client verwendest Du denn?

pgAdmin 4 Version3.5 mit postgreSQL 10

Sorry, keine Ahnung. Ich verwende pgAdmin nicht.