Tom, Stephan,
> Josh Berkus <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
and data management solutions (415) 565-7293
for law firms, small businesses fax 621-2533
and non-profit organizations. San Francisco
