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: BANLkTim_d0ZwLiqssaWd9NZz5Smk5Tq5NQ@mail.gmail.com (view raw or flat)
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 $$
>>> 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
>

In response to

Responses

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-2014 The PostgreSQL Global Development Group