Обсуждение: BUG #3543: ARRAY(SELECT ...) contruct yields NULL without rows
The following bug has been logged online: Bug reference: 3543 Logged by: Jens Schicke Email address: j.schicke@asco.de PostgreSQL version: 8.2.4 Operating system: GNU/Linux Description: ARRAY(SELECT ...) contruct yields NULL without rows Details: SELECT ARRAY(SELECT 1 WHERE 1 = 0) IS NULL; -- true this leads imho to inconsistencies later, if tests with = ANY or similar are done.
On Thu, Aug 16, 2007 at 11:11:49AM +0000, Jens Schicke wrote: >=20 > The following bug has been logged online: >=20 > Bug reference: 3543 > Logged by: Jens Schicke > Email address: j.schicke@asco.de > PostgreSQL version: 8.2.4 > Operating system: GNU/Linux > Description: ARRAY(SELECT ...) contruct yields NULL without rows > Details:=20 >=20 > SELECT ARRAY(SELECT 1 WHERE 1 =3D 0) IS NULL; -- true And just what would you have it return? An array with no elements is by definition NULL. --=20 Decibel!, aka Jim Nasby decibel@decibel.org EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
Decibel! <decibel@decibel.org> writes: > On Thu, Aug 16, 2007 at 11:11:49AM +0000, Jens Schicke wrote: >> SELECT ARRAY(SELECT 1 WHERE 1 = 0) IS NULL; -- true > And just what would you have it return? An array with no elements is by > definition NULL. No, there is a difference: regression=# select null::int4[]; int4 ------ (1 row) regression=# select '{}'::int4[]; int4 ------ {} (1 row) I'm inclined to think that Jens is right and it'd be more consistent to return the latter when the SELECT returns no rows. It'd be a behavioral change more than a bug fix, though, so I would not suggest back-patching it. [ looks at code... ] It looks like the implementation problem is for ExecScanSubPlan to know what the array element type is supposed to be. Normally it finds that out from the sub-select's returned rows; but if there aren't any then it'll have to do something else. regards, tom lane