INSERT..SELECT with GENERATE_SERIES returns error.

On Thu, Dec 18, 2008 at 5:14 PM, Anupama Aherrao <
anupama.aherrao@enterprisedb.com> wrote:

Hi All,

Following INSERT..SELECT with GENERATE_SERIES for bulk insertion returns
error on 8.4 cvs head. It looks like an issue.

Tested on : *8.4 CVS Head*

CREATE TABLE t1 ( x int, y char(4));
INSERT INTO t1 VALUES ( 1, 'edb');
INSERT INTO t1 SELECT 10 + GENERATE_SERIES(50,60), y FROM t1 WHERE
y='edb';
ERROR: unrecognized table-function returnMode: 2822132

Debugged a bit and problem seem to be in ExecMakeFunctionResult().

We prepare a resultinfo node only If function returns set; so "returnMode"
will get set only when function returns is set.

if (fcache->func.fn_retset)
{
.....
/* note we do not set SFRM_Materialize_Random or _Preferred */
rsinfo.returnMode = SFRM_ValuePerCall;
....
}

After calling the function we are looking for the "rsinfo.returnMode" which
is not set in this case. And we endup with error.
Seems like we missing the check for "hasSetArg".

I added the following condition and query worked fine (Not sure how correct
it is).
Inputs ??

diff --git a/src/backend/executor/execQual.c
b/src/backend/executor/execQual.c
index 8df00ed..a23e35e 100644
--- a/src/backend/executor/execQual.c
+++ b/src/backend/executor/execQual.c
@@ -1513,7 +1513,8 @@ restart:
                        }

                        /* Which protocol does function want to use? */
-                       if (rsinfo.returnMode == SFRM_ValuePerCall)
+                       if (rsinfo.returnMode == SFRM_ValuePerCall ||
+                                       (!fcache->func.fn_retset &&
hasSetArg))
                        {
                                if (*isDone != ExprEndResult)
                                {

Thanks,
Rushabh Lathia
www.EnterpriseDB.com

"Anupama Aherrao" <anupama.aherrao@enterprisedb.com> writes:

Following INSERT..SELECT with GENERATE_SERIES for bulk insertion returns
error on 8.4 cvs head. It looks like an issue.

Yeah, looks like I broke this here:
http://archives.postgresql.org/pgsql-committers/2008-10/msg00295.php

Fixed, thanks for the report!

regards, tom lane