From: | Emanuel Calvo <postgres(dot)arg(at)gmail(dot)com> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(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 14:23:27 |
Message-ID: | BANLkTinqSHoCNarnwS4vTx+xjkyWeGypqQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
>>
>> 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 :(.
>
Good point.
> PL/PSM has different philosophy where full check is implemented now.
>
Do you think that make some test in 9.1 worthwhile for this
language? I see that the last contrib was submitted years ago.
Regards,
--
--
Emanuel Calvo
Helpame.com
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2011-05-28 14:36:28 | Re: BUG #6043: Compilation PLpgsql Succesful but execution bad |
Previous Message | Pavel Stehule | 2011-05-28 11:53:50 | Re: BUG #6043: Compilation PLpgsql Succesful but execution bad |