Обсуждение: Huh? Mysterious Function Error

Tom, Stephan, Jan, Etc.
Can you help me with this one?  I can't figure out what is meant by
this error message:

I have a long, complicated PL/pgSQL function called
fn_modify_candidates(INT4,INT4,INT4).

When I call:
SELECT fn_modify_candidate(1004,5,278417036)

I get:
ERROR:  unexpected SELECT query in exec_stmt_execsql()

Help?
                -Josh Berkus

-- 
______AGLIO DATABASE SOLUTIONS___________________________                                       Josh Berkus  Complete
informationtechnology      josh@agliodbs.com   and data management solutions       (415) 565-7293  for law firms, small
businesses      fax  621-2533   and non-profit organizations.       San Francisco
 

Josh Berkus <josh@agliodbs.com> writes:
> ERROR:  unexpected SELECT query in exec_stmt_execsql()

plpgsql doesn't think you should execute bare SELECTs, only SELECT INTO.

On reflection this seems an overly anal-retentive restriction, since
there are cases where one might execute a SELECT for its side effects
alone ("SELECT setval()" comes to mind).

Jan, do you think there's a good case for refusing plain SELECTs?
        regards, tom lane

Does the function have any SELECTs that aren't
SELECT INTOs?

On Tue, 20 Feb 2001, Josh Berkus wrote:

> Tom, Stephan, Jan, Etc.
> 
>     Can you help me with this one?  I can't figure out what is meant by
> this error message:
> 
> I have a long, complicated PL/pgSQL function called
> fn_modify_candidates(INT4,INT4,INT4).
> 
> When I call:
> SELECT fn_modify_candidate(1004,5,278417036)
> 
> I get:
> ERROR:  unexpected SELECT query in exec_stmt_execsql()
> 
> Help?

Tom, Stephan,

> Josh Berkus <josh@agliodbs.com> writes:
> > ERROR:  unexpected SELECT query in exec_stmt_execsql()
> 
> plpgsql doesn't think you should execute bare SELECTs, only SELECT INTO.

That would explain it.  I have a nested function call in the form:

SELECT fn_remove_lock(record_id, user_id);

Because  I didn't care what the function returned and SELECT is the
simplest form.  Easily fixed.

> 
> On reflection this seems an overly anal-retentive restriction, since
> there are cases where one might execute a SELECT for its side effects
> alone ("SELECT setval()" comes to mind).

> Jan, do you think there's a good case for refusing plain SELECTs?

I can think of one, myself.  In some systems (MS SQL Server), all plain
selects are returned by stored procedures as query results; thus a
stored procedure is able to return multiple rowsets.  In other systems,
the single returned rowset is given by the last palin SELECT in the
procedure.

Thus, until PGSQL *does* support stored procedures, refusing plain
SELECTs may be a good way to remind procedure-writers that we do not
have the ability to return rowsets.

For stuff like my procedure, or Tom's example, one can always designate
a dummy variable with:

dummy_variable := setval('some_sq',321);

Which should have the same effect.

-Josh Berkus


-- 
______AGLIO DATABASE SOLUTIONS___________________________                                       Josh Berkus  Complete
informationtechnology      josh@agliodbs.com   and data management solutions       (415) 565-7293  for law firms, small
businesses      fax  621-2533   and non-profit organizations.       San Francisco