Skip site navigation (1) Skip section navigation (2)

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

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Emanuel Calvo <postgres(dot)arg(at)gmail(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #6043: Compilation PLpgsql Succesful but execution bad
Date: 2011-05-28 11:53:50
Message-ID: (view raw or whole thread)
Lists: pgsql-bugs
2011/5/28 Emanuel Calvo <postgres(dot)arg(at)gmail(dot)com>:
> 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 $$
>>> SELECT * FROM p; --<<<-- here must ne RETURN QUERY ..
>>> END;
>>> $$ LANGUAGE plpgsql;
>>> 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.


Pavel Stehule

> Regards,
> E

In response to


pgsql-bugs by date

Next:From: Emanuel CalvoDate: 2011-05-28 14:23:27
Subject: Re: BUG #6043: Compilation PLpgsql Succesful but execution bad
Previous:From: Emanuel CalvoDate: 2011-05-28 09:53:22
Subject: Re: BUG #6043: Compilation PLpgsql Succesful but execution bad

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group