Das legt fest, dass der Parameter als Time interpretiert werden soll (muss).
War mir an der Stelle nicht bewusst, aber damit scheinst du Recht zu haben und das hat mich wiederum auf einen Lösungsansatz gebracht, der wohl funktioniert. Statt "cast(:ende as time)" schreibe ich im
SQL-Statement einfach "cast(cast(:ende as text) as time)" und der Fisch ist geputzt. "24:00" wird nun zuerst mal als String interpretiert und daher auch angenommen, und anschließend erst von Postgres in einen time-Wert umgewandelt.
Wenn du abfragen möchtest, was in der Zeit von 18-0 Uhr gewesen ist und es bei anderen Abfragen keine Überschneidungen geben soll, dann müsste die Abfrage ja eigentlich lauten
Code:
00:00 <= Zeit < 09:00
09:00 <= Zeit < 18:00
18:00<= Zeit < 24:00
BETWEEN fragt aber so ab
Code:
00:00 <= Zeit <= 09:00
09:00 <= Zeit <= 18:00
18:00<= Zeit <= 24:00
Somit würden alle Einträge auf den Zeitgrenzen in den Abfragen quasi doppelt erscheinen.
Besser (und damit stressfreier) wäre es mit BETWEEN die Stunde abzufragen
Code:
0 <= Stunde( Zeit ) <= 8
9 <= Stunde( Zeit ) <= 17
18 <= Stunde( Zeit ) <= 23
Der "between"-Aufruf sollte lediglich ein Beispiel sein an der Stelle und wird in der Form nicht in meiner Anwendung verwendet. Drum brauchst du da nicht weiter drüber nachzudenken. Aber mir ist die Tatsache bewusst, dass "between" sowohl den Anfangs-, als auch den Endzeitpunkt als zum Zeitraum zugehörig ansieht.
Was ist wenn Du den Typecast nach "TIME" weglässt und nur die Zahl übergibst sodass die Umwandlung implizit erfolgt?
Das hätte ich als nächstes ausprobiert, wobei ich dann eher "24:00" als Parameter übergeben würde, als "240000". Bei "between" könnte das noch funktionieren, bei der von mir ebenfalls verwendeten "overlaps"-Funktion von Postgres aber sicher nicht, die erwartet nämlich eindeutige time-Werte und im Falle des Falles einen expliziten Typcast.
Denke ich nicht, dass das klappt, da "today" laut der von dir angegebenen Tabelle nur an die Typen "date, timestamp" zugewiesen werden kann, nicht jedoch time.