Re: BUG #16396: Parallel Union queries seem to treat NULL values differently
От | Tom Lane |
---|---|
Тема | Re: BUG #16396: Parallel Union queries seem to treat NULL values differently |
Дата | |
Msg-id | 22034.1588005652@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #16396: Parallel Union queries seem to treat NULL values differently ("David G. Johnston" <david.g.johnston@gmail.com>) |
Список | pgsql-bugs |
"David G. Johnston" <david.g.johnston@gmail.com> writes: > On Monday, April 27, 2020, PG Bug reporting form <noreply@postgresql.org> > wrote: >> But as in our query the following happened: >> SELECT hello_world >> FROM (SELECT CAST(NULL AS INTEGER) AS hello_world) as a >> UNION >> SELECT hello_world >> FROM (SELECT NULL AS hello_world) as b >> It fails and is only fixable by defining the NULL in the right side of the >> UNION as CAST(NULL AS INTEGER. > In the example the second null is untyped still when it gets fed to the > used and so can be implicitly cast to match the left side of the union. In > you real case the null appears in a subquery under the from clause and > needs to be made into an actual type before it can be passed out of the > subquery and appear in the main query. The resultant type here is text. > Then the union happens and integer and text cannot be melded together. Yeah. I believe this changed in v10, at this commit: https://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=1e7c4bb0049732ece651d993d03bb6772e5d281a Probably that should have been called out as an incompatibility in the v10 release notes, but I don't immediately see anything there that matches. In any case, it's intentional. regards, tom lane
В списке pgsql-bugs по дате отправления: