missing support of named convention for procedures
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t38384psql -h localhost -U postgresBuilt from patchset v7 (message #7), July 27, 2026 at 08:52 PM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t38384_7 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t38384_7 && git checkout t38384_7Patchset v7 (message #7) is on t38384_7
Hi
create or replace procedure proc2(in a int, in b int)
as $$
begin
a := a * 10;
b := b * 10;
end;
$$ language plpgsql;
postgres=# call proc2(a => 10,b => 20);
ERROR: XX000: unrecognized node type: 107
LOCATION: ExecInitExprRec, execExpr.c:2114
Regards
Pavel
2018-03-15 22:13 GMT+01:00 Pavel Stehule <pavel.stehule@gmail.com>:
Hi
create or replace procedure proc2(in a int, in b int)
as $$
begin
a := a * 10;
b := b * 10;
end;
$$ language plpgsql;postgres=# call proc2(a => 10,b => 20);
ERROR: XX000: unrecognized node type: 107
LOCATION: ExecInitExprRec, execExpr.c:2114
Defaults are not supported too:
postgres=# create or replace procedure foo1(a int, b int, c int default 10)
as $$
begin
raise notice 'a: %, b: %, c: %', a, b, c;
end;
$$ language plpgsql;
CREATE PROCEDURE
postgres=# call foo1(10,20);
NOTICE: 00000: a: 10, b: 20, c: -778600432
LOCATION: exec_stmt_raise, pl_exec.c:3643
CALL
Show quoted text
Regards
Pavel
2018-03-16 8:43 GMT+01:00 Pavel Stehule <pavel.stehule@gmail.com>:
2018-03-15 22:13 GMT+01:00 Pavel Stehule <pavel.stehule@gmail.com>:
Hi
create or replace procedure proc2(in a int, in b int)
as $$
begin
a := a * 10;
b := b * 10;
end;
$$ language plpgsql;postgres=# call proc2(a => 10,b => 20);
ERROR: XX000: unrecognized node type: 107
LOCATION: ExecInitExprRec, execExpr.c:2114Defaults are not supported too:
postgres=# create or replace procedure foo1(a int, b int, c int default
10)
as $$
begin
raise notice 'a: %, b: %, c: %', a, b, c;
end;
$$ language plpgsql;
CREATE PROCEDURE
postgres=# call foo1(10,20);
NOTICE: 00000: a: 10, b: 20, c: -778600432
LOCATION: exec_stmt_raise, pl_exec.c:3643
CALL
attached patch fixes it
Regards
Pavel
Show quoted text
Regards
Pavel
Attachments:
plpgsql-call-named-default-args.patchtext/x-patch; charset=US-ASCII; name=plpgsql-call-named-default-args.patchDownload+179-11
2018-03-16 11:29 GMT+01:00 Pavel Stehule <pavel.stehule@gmail.com>:
2018-03-16 8:43 GMT+01:00 Pavel Stehule <pavel.stehule@gmail.com>:
2018-03-15 22:13 GMT+01:00 Pavel Stehule <pavel.stehule@gmail.com>:
Hi
create or replace procedure proc2(in a int, in b int)
as $$
begin
a := a * 10;
b := b * 10;
end;
$$ language plpgsql;postgres=# call proc2(a => 10,b => 20);
ERROR: XX000: unrecognized node type: 107
LOCATION: ExecInitExprRec, execExpr.c:2114Defaults are not supported too:
postgres=# create or replace procedure foo1(a int, b int, c int default
10)
as $$
begin
raise notice 'a: %, b: %, c: %', a, b, c;
end;
$$ language plpgsql;
CREATE PROCEDURE
postgres=# call foo1(10,20);
NOTICE: 00000: a: 10, b: 20, c: -778600432
LOCATION: exec_stmt_raise, pl_exec.c:3643
CALLattached patch fixes it
Regards
Pavel
variadic parameters are supported too.
Show quoted text
Regards
Pavel
On 3/16/18 06:29, Pavel Stehule wrote:
attached patch fixes it
The fix doesn't seem to work for LANGUAGE SQL procedures. For example:
CREATE PROCEDURE ptest5(a int, b int DEFAULT 0)
LANGUAGE SQL
AS $$
INSERT INTO cp_test VALUES (a, 'foo');
INSERT INTO cp_test VALUES (b, 'bar');
$$;
CALL ptest5(a => 1, b => 2); -- ok
CALL ptest5(b => 3, a => 4); -- ok
CALL ptest5(5);
ERROR: no value found for parameter 2
CONTEXT: SQL function "ptest5" statement 2
CALL ptest5(a => 6);
ERROR: no value found for parameter 2
CONTEXT: SQL function "ptest5" statement 2
I'm not quite sure why this behaves differently from plpgsql. Needs
more digging.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
2018-03-20 17:31 GMT+01:00 Peter Eisentraut <
peter.eisentraut@2ndquadrant.com>:
On 3/16/18 06:29, Pavel Stehule wrote:
attached patch fixes it
The fix doesn't seem to work for LANGUAGE SQL procedures. For example:
CREATE PROCEDURE ptest5(a int, b int DEFAULT 0)
LANGUAGE SQL
AS $$
INSERT INTO cp_test VALUES (a, 'foo');
INSERT INTO cp_test VALUES (b, 'bar');
$$;
CALL ptest5(a => 1, b => 2); -- ok
CALL ptest5(b => 3, a => 4); -- ok
CALL ptest5(5);
ERROR: no value found for parameter 2
CONTEXT: SQL function "ptest5" statement 2
CALL ptest5(a => 6);
ERROR: no value found for parameter 2
CONTEXT: SQL function "ptest5" statement 2I'm not quite sure why this behaves differently from plpgsql. Needs
more digging.
Do you working on this issue? Maybe tomorrow I'll have a time to look there.
Regards
Pavel
Show quoted text
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Hi
2018-03-21 8:18 GMT+01:00 Pavel Stehule <pavel.stehule@gmail.com>:
2018-03-20 17:31 GMT+01:00 Peter Eisentraut <peter.eisentraut@2ndquadrant.
com>:On 3/16/18 06:29, Pavel Stehule wrote:
attached patch fixes it
The fix doesn't seem to work for LANGUAGE SQL procedures. For example:
CREATE PROCEDURE ptest5(a int, b int DEFAULT 0)
LANGUAGE SQL
AS $$
INSERT INTO cp_test VALUES (a, 'foo');
INSERT INTO cp_test VALUES (b, 'bar');
$$;
CALL ptest5(a => 1, b => 2); -- ok
CALL ptest5(b => 3, a => 4); -- ok
CALL ptest5(5);
ERROR: no value found for parameter 2
CONTEXT: SQL function "ptest5" statement 2
CALL ptest5(a => 6);
ERROR: no value found for parameter 2
CONTEXT: SQL function "ptest5" statement 2I'm not quite sure why this behaves differently from plpgsql. Needs
more digging.Do you working on this issue? Maybe tomorrow I'll have a time to look
there.
attached patch should to fix it
Regards
Pavel
Show quoted text
Regards
Pavel
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Hi Peter, Pavel,
On 2018-03-22 15:19:12 +0100, Pavel Stehule wrote:
attached patch should to fix it
This is still broken, and has been an open item for a bit. Peter, Could
you check whether Pavel's fix resolves the issue for you?
Regards,
Andres
On 4/11/18 12:06, Andres Freund wrote:
On 2018-03-22 15:19:12 +0100, Pavel Stehule wrote:
attached patch should to fix it
This is still broken, and has been an open item for a bit. Peter, Could
you check whether Pavel's fix resolves the issue for you?
Yes, I will work on this.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 3/22/18 10:19, Pavel Stehule wrote:
attached patch should to fix it
Committed.
I had to make a small tweak to make INOUT + DEFAULT parameters work in
PL/pgSQL.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
2018-04-14 15:58 GMT+02:00 Peter Eisentraut <
peter.eisentraut@2ndquadrant.com>:
On 3/22/18 10:19, Pavel Stehule wrote:
attached patch should to fix it
Committed.
Thank you
Pavel
Show quoted text
I had to make a small tweak to make INOUT + DEFAULT parameters work in
PL/pgSQL.--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services