Re: BUG #6043: Compilation PLpgsql Succesful but execution bad
От | Emanuel Calvo |
---|---|
Тема | Re: BUG #6043: Compilation PLpgsql Succesful but execution bad |
Дата | |
Msg-id | BANLkTinqSHoCNarnwS4vTx+xjkyWeGypqQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #6043: Compilation PLpgsql Succesful but execution bad (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: BUG #6043: Compilation PLpgsql Succesful but execution bad
|
Список | 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 - =C2=A0this > 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, --=20 -- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Emanuel Calvo =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Helpame.com
В списке pgsql-bugs по дате отправления: