2011/5/28 Emanuel Calvo <postgres....@gmail.com>: > El 27/05/2011 16:18, "Heikki Linnakangas" > <heikki.linnakan...@enterprisedb.com> escribió: >> On 27.05.2011 17:05, Emanuel wrote: >>> postgres=# CREATE OR REPLACE FUNCTION p_() RETURNS TABLE (i int) AS $$ >>> DECLARE >>> BEGIN >>> SELECT * FROM p; --<<<-- here must ne RETURN QUERY .. >>> END; >>> $$ LANGUAGE plpgsql; >>> CREATE FUNCTION >>> postgres=# select p_(); >>> ERROR: query has no destination for result data >>> HINT: If you want to discard the results of a SELECT, use PERFORM >>> instead. >>> CONTEXT: PL/pgSQL function "p_" line 4 at SQL statement >>> >>> I don't know if it's really a bug or a feature request. But seems that >>> the >>> function compiles well without checking the existence of a RETURN QUERY. >>> I >>> think the best in this cases is raise an error during compilation. > > Thanks Heikki for your fast response! ^^ > > >> The compiler would have to determine that the loop never ends, or it >> would complain that there's no RETURN at the end. >> >> Many compilers for other languages do that kind of analysis, but it >> usually only results in a warning, and compilers sometimes get that >> wrong. I don't think it's worthwhile to do that, but of course, patches >> are welcome. >> > > Yeah, it's not a very big concern, althougth cold be taken for future > improvements > in plpgsql. I very far for submit a patch :P >
The deep check of embedded SQL is not possible in PL/pgSQL - this remove dependency between PL/pgSQL and database objects. Deeper checks mean a broken compatibility :(. PL/PSM has different philosophy where full check is implemented now. Regards Pavel Stehule > Regards, > E > -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
