The following bug has been logged on the website:
Bug reference: 18081
Logged by: Branko Radovanovic
Email address: branko.radovanovic.zg@gmail.com
PostgreSQL version: 13.5
Operating system: Debian 8.3.0
Description:
When executing the following sequence of statements:
CREATE OR REPLACE PROCEDURE proc(param text default 'n/a')
LANGUAGE plpgsql
AS $procedure$
BEGIN
raise info 'proc(%)', param;
END;
$procedure$;
CREATE OR REPLACE PROCEDURE test1()
LANGUAGE plpgsql
AS $procedure$
BEGIN
call proc();
END;
$procedure$;
CREATE OR REPLACE PROCEDURE proc()
LANGUAGE plpgsql
AS $procedure$
BEGIN
raise info 'proc()';
END;
$procedure$;
DROP PROCEDURE proc(text);
CREATE OR REPLACE PROCEDURE test2()
LANGUAGE plpgsql
AS $procedure$
BEGIN
call proc();
END;
$procedure$;
call test2(); --#A
call test1(); --#B
...statement #A will output:
proc()
...which is as expected, while statement #B will throw an error:
SQL Error [42883]: ERROR: function with OID 102048 does not exist
Where: SQL statement "CALL proc()"
PL/pgSQL function test1() line 3 at CALL
I get this behavior in versions 13.5 and 14.9. This is strange because it
would imply that:
1) It is possible to have two procedures with identical bodies, one of which
works while the other does not
2) The way a procedure behaves is dependent on the state of the database in
the instant the procedure was created
Both of these conclusions break the mental model of plpgsql as being fully
interpreted. On top of that, this sort of situation cannot be detected by
parsing tools such as plpgsql_check nor by human review, as nothing is wrong
with the code itself. I would argue that #B should work exactly the same as
#A.
Best regards,
Branko Radovanovic
