Re: INSERT..SELECT with GENERATE_SERIES returns error.

From: "Rushabh Lathia" <rushabh(dot)lathia(at)gmail(dot)com>
To: "Anupama Aherrao" <anupama(dot)aherrao(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Cc: rushabh(dot)lathia(at)enterprisedb(dot)com
Subject: Re: INSERT..SELECT with GENERATE_SERIES returns error.
Date: 2008-12-18 12:08:26
Message-ID: 460abcb10812180408v25b7c687u84403f7d674b0f67@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Dec 18, 2008 at 5:14 PM, Anupama Aherrao <
anupama(dot)aherrao(at)enterprisedb(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2008-12-18 12:16:40 Re: Preventing index scans for non-recoverable index AMs
Previous Message Peter Eisentraut 2008-12-18 11:52:32 Re: Preventing index scans for non-recoverable index AMs