From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | brandstetter(at)falter(dot)at |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #8150: NULL emements lost when casting result of unnest() |
Date: | 2013-05-11 15:13:44 |
Message-ID: | 16834.1368285224@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
brandstetter(at)falter(dot)at writes:
> SELECT unnest('{1,NULL,4}'::int[])::int8;
> i
> ---
> 1
> 4
Hm ... this seems to be a very old oversight in ExecMakeFunctionResult:
when it's dealing with a set-valued function argument, if the function
is strict and the particular input value is NULL, it sets the isDone
flag to ExprEndResult, ie, empty-set result. I think this is the right
thing if the current function returns set; but for a non-set-returning
function, what we ought to get is a scalar NULL result not an empty set.
Various other code paths including ExecMakeTableFunctionResult appear to
get this right.
The attached patch fixes it.
This is another case where I'm not too sure if we ought to back-patch.
The current behavior is clearly wrong, but perhaps some application
out there will be unhappy if we change it in back branches?
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
fix-strict-non-srf-for-nulls.patch | text/x-patch | 1.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Erik Rijkers | 2013-05-11 15:26:19 | Re: BUG #8150: NULL emements lost when casting result of unnest() |
Previous Message | brandstetter | 2013-05-11 12:22:48 | BUG #8150: NULL emements lost when casting result of unnest() |