From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Decibel! <decibel(at)decibel(dot)org> |
Cc: | Jens Schicke <j(dot)schicke(at)asco(dot)de>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #3543: ARRAY(SELECT ...) contruct yields NULL without rows |
Date: | 2007-08-16 15:00:21 |
Message-ID: | 3764.1187276421@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Decibel! <decibel(at)decibel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Stephan Szabo | 2007-08-16 15:02:16 | Re: BUG #3542: Dropped and recreated columns have problems with NOT NULL contraints |
Previous Message | Decibel! | 2007-08-16 14:09:11 | Re: BUG #3543: ARRAY(SELECT ...) contruct yields NULL without rows |