Statement flicken
Biesterfeld
- datenbank
1 Vinzenz Mai0 Hamstar
Hej,
ich hoffe hier kennt sich der ein oder andere ein bisschen mit Postgres aus. Folgendes Statement:
SELECT met_en,
sum( CASE WHEN rev THEN 1 ELSE 0 END ) AS r,
sum( CASE WHEN ( NOT rev AND net < 0 ) THEN 1 ELSE 0 END ) AS e,
sum( CASE WHEN ( NOT rev AND net > 0 ) THEN 1 ELSE 0 END ) AS p
FROM st
WHERE net != 0
GROUP BY met_en
HAVING ( r > 1 )
OR ( e > 0 AND ( r > 0 OR p > 0 ) )
OR ( p > 0 AND ( r > 0 OR e > 0 ) )
Angeblich ist das Statemen fehlerhaft, weil "Spalte r unbekannt ist". Ichhab auf Anhieb aber keine Möglichkeit gefunden, anders auf die etwas aufwendigen Aggregatfunktionen zuzugreifen ohne sie in der HAVING-Klausel wieder niederzuschreiben.
Kann ich das doch irgendwie mit Aliasen machen?
Falls nicht: Würden die Aggregatfunktionen für jedes mal wo sie in HAVING
erscheinen müssten erneut ausgewerted oder rafft Postgres dass das jeweils der gleiche Asudruck mit gleichem Ergebnis ist?
Beste Grüße
Biesterfeld
Hallo,
ich hoffe hier kennt sich der ein oder andere ein bisschen mit Postgres aus. Folgendes Statement:
ich habe zwar wenig Erfahrung mit PostgreSQL, genauer gesagt nur soviel wie für meinen Artikel und eine Antwort für ein schon etwas komplexeres Problem hier im Forum nötig war.
Angeblich ist das Statemen fehlerhaft, weil "Spalte r unbekannt ist". Ichhab auf Anhieb aber keine Möglichkeit gefunden, anders auf die etwas aufwendigen Aggregatfunktionen zuzugreifen ohne sie in der HAVING-Klausel wieder niederzuschreiben.
Kann ich das doch irgendwie mit Aliasen machen?
Ich habe folgenden Artikel gefunden, der interessante Einblicke in die Abarbeitung von SELECT-Statements bietet - und zumindest für die Version 7.3 Deine Frage mit "Nein" beantwortet.
Zur Performance: Testen, Messen, Ausführungspläne anschauen.
Freundliche Grüße
Vinzenz
Hej,
Ich habe folgenden Artikel gefunden, der interessante Einblicke in die Abarbeitung von SELECT-Statements bietet - und zumindest für die Version 7.3 Deine Frage mit "Nein" beantwortet.
Jau, ist zwar einerseits schade, aber der Artikel hat mich auf die Idee gebracht es natürlich auch folgendermaßen machen zu können, was sowohl vom Ergebnis, als auch von der Ausführung äquivalent sein sollte:
SELECT met_en, use.r, use.e, use.p
FROM (
SELECT met_en,
sum( CASE WHEN rev THEN 1 ELSE 0 END ) AS r,
sum( CASE WHEN ( NOT rev AND net < 0 ) THEN 1 ELSE 0 END ) AS e,
sum( CASE WHEN ( NOT rev AND net > 0 ) THEN 1 ELSE 0 END ) AS p
FROM st
WHERE net != 0
GROUP BY met_en
) AS use
WHERE ( use.r > 1 )
OR ( use.e > 0 AND ( use.r > 0 OR use.p > 0 ) )
OR ( use.p > 0 AND ( use.r > 0 OR use.e > 0 ) )
Vielen Dank
Biesterfeld
HAVING ( r > 1 )
OR ( e > 0 AND ( r > 0 OR p > 0 ) )
OR ( p > 0 AND ( r > 0 OR e > 0 ) )
Mach ein Sub-SELECT als workaround, ausserdem empfehle ich sinnvolle Datenfeldnamen und Aliasnamen.