Re: INOUT parameters in procedures
От | Peter Eisentraut |
---|---|
Тема | Re: INOUT parameters in procedures |
Дата | |
Msg-id | 922a0ffb-bce9-d864-e7cc-bbbe26782b01@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: INOUT parameters in procedures (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: INOUT parameters in procedures
|
Список | pgsql-hackers |
On 3/6/18 04:22, Pavel Stehule wrote: > why just OUT variables are disallowed? > > The oracle initializes these values to NULL - we can do same? The problem is function call resolution. If we see a call like CALL foo(a, b, c); the this could be foo() with zero input and three output parameters, or with one input parameter and two output parameters, etc. We have no code to deal with that right now. > Minimally this message is not too friendly, there should be hint - "only > INOUT is suported" - but better support OUT too - from TOP OUT variables > should not be passed. from PL should be required. Added a hint. > I wrote recursive procedure. The call finished by exception. Why? Fixed. (memory context issue) I added your example as a test case. > This issue can be detected in compile time, maybe? > > postgres=# create or replace procedure p(x int,inout a int, inout b numeric) > as $$ > begin raise notice 'xxx % %', a, b;if (x > 1) then > a := x / 10; > b := x / 2; call p(b::int, a, 10); <--- can be detected in compile time? > end if; > end; > $$ language plpgsql; Function resolution doesn't happen at compile time. That would require significant work in PL/pgSQL (possible perhaps, but major work). Right now, we do parse analysis at first execution. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Вложения
В списке pgsql-hackers по дате отправления: