Biesterfeld: Statement flicken

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

--
Art.1: Et es wie et es
Art.2: Et kütt wie et kütt
Art.3: Et hätt noch immer jot jejange
Das Kölsche Grundgesetz
  1. 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

    1. 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

      --
      Art.1: Et es wie et es
      Art.2: Et kütt wie et kütt
      Art.3: Et hätt noch immer jot jejange
      Das Kölsche Grundgesetz
  2. 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.