2011/5/28 Emanuel Calvo <postgres.arg@gmail.com>:
> El 27/05/2011 16:18, "Heikki Linnakangas"
> <heikki.linnakangas@enterprisedb.com> escribi=C3=B3:
>> On 27.05.2011 17:05, Emanuel wrote:
>>> postgres=3D# 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=3D# 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
>
