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
