Re: INSERT..SELECT with GENERATE_SERIES returns error. - Mailing list pgsql-hackers

From Rushabh Lathia
Subject Re: INSERT..SELECT with GENERATE_SERIES returns error.
Date
Msg-id 460abcb10812180408v25b7c687u84403f7d674b0f67@mail.gmail.com
Whole thread Raw
In response to INSERT..SELECT with GENERATE_SERIES returns error.  ("Anupama Aherrao" <anupama.aherrao@enterprisedb.com>)
List pgsql-hackers


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

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Preventing index scans for non-recoverable index AMs
Next
From: Simon Riggs
Date:
Subject: Re: Preventing index scans for non-recoverable index AMs