Re: Huh? Mysterious Function Error

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