Re: Huh? Mysterious Function Error

Tom, Stephan,

> Josh Berkus <josh(at)agliodbs(dot)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 information technology josh(at)agliodbs(dot)com
and data management solutions (415) 565-7293
for law firms, small businesses fax 621-2533
and non-profit organizations. San Francisco