Bug?

Hallo zusammen,

kann mir jemand folgendes Phänomen erklaeren?

Funktionierendes Statement:

select * from (
    select null, 1
    union all
    select '00:00:00'::interval, 3
) as n

NICHT funktionierendes Statement:

select * from (
    select null, 1
    union all
    select null, 2
    union all
    select '00:00:00'::interval, 3
) as n
/*
ERROR:  UNION types text and interval cannot be matched
LINE 6:  select '00:00:00'::interval, 3
                ^
********** Fehler **********
ERROR: UNION types text and interval cannot be matched
SQL Status:42804
Zeichen:79
*/

Woher nimmt Postgres plötzlich die Gewissheit, dass das Ergebnis vom Typ ::text sein soll?

Bis dahin beste Grüße

Woher nimmst Du die Gewissheit, daß ein select NULL; ein INTERVAL liefert?

Andreas

hallo Andreas

ich weiss - man kann das alles casten.

Das thema ist hibernate - was mir eine dieser queries erzeugt.
Ich passe gerade den PG-Dialect dafuer an und hoffte nun, dass ohne expliziten typen die null-Spalten einfach an den Typen des ersten Bekannten gebunden werden.

In dem Beispiel siehst du, dass alle sonstigen Queries null liefern, nur diese Eine eben nicht. D.h. die einzige sicher Wahl wäre ™ ::interval … weil alle anderen Selects null sagen.

Casten ist leider keine Option, weil das einzige was ich von der spalte weiss ist der JDBC-Type OTHER … D.h. ich kann den Typen eigentlich nur weglassen und hoffen, dass PG schlau genuch ist.

Gruß

Nun, ich denke, das Problem ist folgendes:

nach dem ersten UNION hat PG eine Tabelle zu bilden, und zu diesem Zeitpunkt sieht es 2 mal NULL und entscheidet sich daher für den dümmsten aller Datentypen: TEXT. Zumindest vermute ich, daß es so abläuft.

Wie Du damit nun umgehst überlasse ich Dir.


Andreas

ich habe dazu noch folgendes gefunden:
Re: BUG #1677: Bug in select with Union

mist :slight_smile:

verstecken sie sich wieder hinter der sql-spect g