Re: BUG #6043: Compilation PLpgsql Succesful but execution bad

From: Emanuel Calvo <postgres(dot)arg(at)gmail(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #6043: Compilation PLpgsql Succesful but execution bad
Date: 2011-05-28 09:53:22
Message-ID: BANLkTiksk+sNoPKzJV573FycQnUQ31_EQg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

El 27/05/2011 16:18, "Heikki Linnakangas" <
heikki(dot)linnakangas(at)enterprisedb(dot)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

Regards,
E

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Pavel Stehule 2011-05-28 11:53:50 Re: BUG #6043: Compilation PLpgsql Succesful but execution bad
Previous Message Alvaro Herrera 2011-05-28 05:06:42 Re: 9.1 plperlu bug with null rows in trigger hash