2017-11-30 14:46:13 +01:00
|
|
|
CALL nonexistent(); -- error
|
2018-07-07 11:17:04 +02:00
|
|
|
ERROR: procedure nonexistent() does not exist
|
2017-11-30 14:46:13 +01:00
|
|
|
LINE 1: CALL nonexistent();
|
|
|
|
^
|
2018-07-07 11:17:04 +02:00
|
|
|
HINT: No procedure matches the given name and argument types. You might need to add explicit type casts.
|
2017-11-30 14:46:13 +01:00
|
|
|
CALL random(); -- error
|
|
|
|
ERROR: random() is not a procedure
|
|
|
|
LINE 1: CALL random();
|
|
|
|
^
|
|
|
|
HINT: To call a function, use SELECT.
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
CREATE FUNCTION cp_testfunc1(a int) RETURNS int LANGUAGE SQL AS $$ SELECT a $$;
|
2017-11-30 14:46:13 +01:00
|
|
|
CREATE TABLE cp_test (a int, b text);
|
|
|
|
CREATE PROCEDURE ptest1(x text)
|
|
|
|
LANGUAGE SQL
|
|
|
|
AS $$
|
|
|
|
INSERT INTO cp_test VALUES (1, x);
|
|
|
|
$$;
|
|
|
|
\df ptest1
|
|
|
|
List of functions
|
|
|
|
Schema | Name | Result data type | Argument data types | Type
|
|
|
|
--------+--------+------------------+---------------------+------
|
Reconsider the handling of procedure OUT parameters.
Commit 2453ea142 redefined pg_proc.proargtypes to include the types of
OUT parameters, for procedures only. While that had some advantages
for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty
disastrous from a number of other perspectives. Notably, since the
primary key of pg_proc is name + proargtypes, this made it possible to
have multiple procedures with identical names + input arguments and
differing output argument types. That would make it impossible to call
any one of the procedures by writing just NULL (or "?", or any other
data-type-free notation) for the output argument(s). The change also
seems likely to cause grave confusion for client applications that
examine pg_proc and expect the traditional definition of proargtypes.
Hence, revert the definition of proargtypes to what it was, and
undo a number of complications that had been added to support that.
To support the SQL-spec behavior of DROP PROCEDURE, when there are
no argmode markers in the command's parameter list, we perform the
lookup both ways (that is, matching against both proargtypes and
proallargtypes), succeeding if we get just one unique match.
In principle this could result in ambiguous-function failures
that would not happen when using only one of the two rules.
However, overloading of procedure names is thought to be a pretty
rare usage, so this shouldn't cause many problems in practice.
Postgres-specific code such as pg_dump can defend against any
possibility of such failures by being careful to specify argmodes
for all procedure arguments.
This also fixes a few other bugs in the area of CALL statements
with named parameters, and improves the documentation a little.
catversion bump forced because the representation of procedures
with OUT arguments changes.
Discussion: https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us
2021-06-10 23:11:36 +02:00
|
|
|
public | ptest1 | | IN x text | proc
|
2017-11-30 14:46:13 +01:00
|
|
|
(1 row)
|
|
|
|
|
2018-02-13 16:34:04 +01:00
|
|
|
SELECT pg_get_functiondef('ptest1'::regproc);
|
Reconsider the handling of procedure OUT parameters.
Commit 2453ea142 redefined pg_proc.proargtypes to include the types of
OUT parameters, for procedures only. While that had some advantages
for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty
disastrous from a number of other perspectives. Notably, since the
primary key of pg_proc is name + proargtypes, this made it possible to
have multiple procedures with identical names + input arguments and
differing output argument types. That would make it impossible to call
any one of the procedures by writing just NULL (or "?", or any other
data-type-free notation) for the output argument(s). The change also
seems likely to cause grave confusion for client applications that
examine pg_proc and expect the traditional definition of proargtypes.
Hence, revert the definition of proargtypes to what it was, and
undo a number of complications that had been added to support that.
To support the SQL-spec behavior of DROP PROCEDURE, when there are
no argmode markers in the command's parameter list, we perform the
lookup both ways (that is, matching against both proargtypes and
proallargtypes), succeeding if we get just one unique match.
In principle this could result in ambiguous-function failures
that would not happen when using only one of the two rules.
However, overloading of procedure names is thought to be a pretty
rare usage, so this shouldn't cause many problems in practice.
Postgres-specific code such as pg_dump can defend against any
possibility of such failures by being careful to specify argmodes
for all procedure arguments.
This also fixes a few other bugs in the area of CALL statements
with named parameters, and improves the documentation a little.
catversion bump forced because the representation of procedures
with OUT arguments changes.
Discussion: https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us
2021-06-10 23:11:36 +02:00
|
|
|
pg_get_functiondef
|
|
|
|
------------------------------------------------------
|
|
|
|
CREATE OR REPLACE PROCEDURE public.ptest1(IN x text)+
|
|
|
|
LANGUAGE sql +
|
|
|
|
AS $procedure$ +
|
|
|
|
INSERT INTO cp_test VALUES (1, x); +
|
|
|
|
$procedure$ +
|
2018-02-13 16:34:04 +01:00
|
|
|
|
|
|
|
(1 row)
|
|
|
|
|
2018-07-14 12:17:49 +02:00
|
|
|
-- show only normal functions
|
|
|
|
\dfn public.*test*1
|
|
|
|
List of functions
|
|
|
|
Schema | Name | Result data type | Argument data types | Type
|
|
|
|
--------+--------------+------------------+---------------------+------
|
|
|
|
public | cp_testfunc1 | integer | a integer | func
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- show only procedures
|
|
|
|
\dfp public.*test*1
|
|
|
|
List of functions
|
|
|
|
Schema | Name | Result data type | Argument data types | Type
|
|
|
|
--------+--------+------------------+---------------------+------
|
Reconsider the handling of procedure OUT parameters.
Commit 2453ea142 redefined pg_proc.proargtypes to include the types of
OUT parameters, for procedures only. While that had some advantages
for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty
disastrous from a number of other perspectives. Notably, since the
primary key of pg_proc is name + proargtypes, this made it possible to
have multiple procedures with identical names + input arguments and
differing output argument types. That would make it impossible to call
any one of the procedures by writing just NULL (or "?", or any other
data-type-free notation) for the output argument(s). The change also
seems likely to cause grave confusion for client applications that
examine pg_proc and expect the traditional definition of proargtypes.
Hence, revert the definition of proargtypes to what it was, and
undo a number of complications that had been added to support that.
To support the SQL-spec behavior of DROP PROCEDURE, when there are
no argmode markers in the command's parameter list, we perform the
lookup both ways (that is, matching against both proargtypes and
proallargtypes), succeeding if we get just one unique match.
In principle this could result in ambiguous-function failures
that would not happen when using only one of the two rules.
However, overloading of procedure names is thought to be a pretty
rare usage, so this shouldn't cause many problems in practice.
Postgres-specific code such as pg_dump can defend against any
possibility of such failures by being careful to specify argmodes
for all procedure arguments.
This also fixes a few other bugs in the area of CALL statements
with named parameters, and improves the documentation a little.
catversion bump forced because the representation of procedures
with OUT arguments changes.
Discussion: https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us
2021-06-10 23:11:36 +02:00
|
|
|
public | ptest1 | | IN x text | proc
|
2018-07-14 12:17:49 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT ptest1('x'); -- error
|
|
|
|
ERROR: ptest1(unknown) is a procedure
|
|
|
|
LINE 1: SELECT ptest1('x');
|
|
|
|
^
|
|
|
|
HINT: To call a procedure, use CALL.
|
|
|
|
CALL ptest1('a'); -- ok
|
|
|
|
CALL ptest1('xy' || 'zzy'); -- ok, constant-folded arg
|
|
|
|
CALL ptest1(substring(random()::numeric(20,15)::text, 1, 1)); -- ok, volatile arg
|
Avoid premature free of pass-by-reference CALL arguments.
Prematurely freeing the EState used to evaluate CALL arguments led, in some
cases, to passing dangling pointers to the procedure. This was masked in
trivial cases because the argument pointers would point to Const nodes in
the original expression tree, and in some other cases because the result
value would end up in the standalone ExprContext rather than in memory
belonging to the EState --- but that wasn't exactly high quality
programming either, because the standalone ExprContext was never
explicitly freed, breaking assorted API contracts.
In addition, using a separate EState for each argument was just silly.
So let's use just one EState, and one ExprContext, and make the latter
belong to the former rather than be standalone, and clean up the EState
(and hence the ExprContext) post-call.
While at it, improve the function's commentary a bit.
Discussion: https://postgr.es/m/29173.1518282748@sss.pgh.pa.us
2018-02-10 19:37:12 +01:00
|
|
|
SELECT * FROM cp_test ORDER BY b COLLATE "C";
|
|
|
|
a | b
|
|
|
|
---+-------
|
|
|
|
1 | 0
|
2017-11-30 14:46:13 +01:00
|
|
|
1 | a
|
Avoid premature free of pass-by-reference CALL arguments.
Prematurely freeing the EState used to evaluate CALL arguments led, in some
cases, to passing dangling pointers to the procedure. This was masked in
trivial cases because the argument pointers would point to Const nodes in
the original expression tree, and in some other cases because the result
value would end up in the standalone ExprContext rather than in memory
belonging to the EState --- but that wasn't exactly high quality
programming either, because the standalone ExprContext was never
explicitly freed, breaking assorted API contracts.
In addition, using a separate EState for each argument was just silly.
So let's use just one EState, and one ExprContext, and make the latter
belong to the former rather than be standalone, and clean up the EState
(and hence the ExprContext) post-call.
While at it, improve the function's commentary a bit.
Discussion: https://postgr.es/m/29173.1518282748@sss.pgh.pa.us
2018-02-10 19:37:12 +01:00
|
|
|
1 | xyzzy
|
|
|
|
(3 rows)
|
2017-11-30 14:46:13 +01:00
|
|
|
|
2021-04-07 21:30:08 +02:00
|
|
|
-- SQL-standard body
|
|
|
|
CREATE PROCEDURE ptest1s(x text)
|
|
|
|
LANGUAGE SQL
|
|
|
|
BEGIN ATOMIC
|
|
|
|
INSERT INTO cp_test VALUES (1, x);
|
|
|
|
END;
|
|
|
|
\df ptest1s
|
|
|
|
List of functions
|
|
|
|
Schema | Name | Result data type | Argument data types | Type
|
|
|
|
--------+---------+------------------+---------------------+------
|
Reconsider the handling of procedure OUT parameters.
Commit 2453ea142 redefined pg_proc.proargtypes to include the types of
OUT parameters, for procedures only. While that had some advantages
for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty
disastrous from a number of other perspectives. Notably, since the
primary key of pg_proc is name + proargtypes, this made it possible to
have multiple procedures with identical names + input arguments and
differing output argument types. That would make it impossible to call
any one of the procedures by writing just NULL (or "?", or any other
data-type-free notation) for the output argument(s). The change also
seems likely to cause grave confusion for client applications that
examine pg_proc and expect the traditional definition of proargtypes.
Hence, revert the definition of proargtypes to what it was, and
undo a number of complications that had been added to support that.
To support the SQL-spec behavior of DROP PROCEDURE, when there are
no argmode markers in the command's parameter list, we perform the
lookup both ways (that is, matching against both proargtypes and
proallargtypes), succeeding if we get just one unique match.
In principle this could result in ambiguous-function failures
that would not happen when using only one of the two rules.
However, overloading of procedure names is thought to be a pretty
rare usage, so this shouldn't cause many problems in practice.
Postgres-specific code such as pg_dump can defend against any
possibility of such failures by being careful to specify argmodes
for all procedure arguments.
This also fixes a few other bugs in the area of CALL statements
with named parameters, and improves the documentation a little.
catversion bump forced because the representation of procedures
with OUT arguments changes.
Discussion: https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us
2021-06-10 23:11:36 +02:00
|
|
|
public | ptest1s | | IN x text | proc
|
2021-04-07 21:30:08 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT pg_get_functiondef('ptest1s'::regproc);
|
Reconsider the handling of procedure OUT parameters.
Commit 2453ea142 redefined pg_proc.proargtypes to include the types of
OUT parameters, for procedures only. While that had some advantages
for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty
disastrous from a number of other perspectives. Notably, since the
primary key of pg_proc is name + proargtypes, this made it possible to
have multiple procedures with identical names + input arguments and
differing output argument types. That would make it impossible to call
any one of the procedures by writing just NULL (or "?", or any other
data-type-free notation) for the output argument(s). The change also
seems likely to cause grave confusion for client applications that
examine pg_proc and expect the traditional definition of proargtypes.
Hence, revert the definition of proargtypes to what it was, and
undo a number of complications that had been added to support that.
To support the SQL-spec behavior of DROP PROCEDURE, when there are
no argmode markers in the command's parameter list, we perform the
lookup both ways (that is, matching against both proargtypes and
proallargtypes), succeeding if we get just one unique match.
In principle this could result in ambiguous-function failures
that would not happen when using only one of the two rules.
However, overloading of procedure names is thought to be a pretty
rare usage, so this shouldn't cause many problems in practice.
Postgres-specific code such as pg_dump can defend against any
possibility of such failures by being careful to specify argmodes
for all procedure arguments.
This also fixes a few other bugs in the area of CALL statements
with named parameters, and improves the documentation a little.
catversion bump forced because the representation of procedures
with OUT arguments changes.
Discussion: https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us
2021-06-10 23:11:36 +02:00
|
|
|
pg_get_functiondef
|
|
|
|
-------------------------------------------------------
|
|
|
|
CREATE OR REPLACE PROCEDURE public.ptest1s(IN x text)+
|
|
|
|
LANGUAGE sql +
|
|
|
|
BEGIN ATOMIC +
|
|
|
|
INSERT INTO cp_test (a, b) +
|
|
|
|
VALUES (1, ptest1s.x); +
|
|
|
|
END +
|
2021-04-07 21:30:08 +02:00
|
|
|
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
CALL ptest1s('b');
|
|
|
|
SELECT * FROM cp_test ORDER BY b COLLATE "C";
|
|
|
|
a | b
|
|
|
|
---+-------
|
|
|
|
1 | 0
|
|
|
|
1 | a
|
|
|
|
1 | b
|
|
|
|
1 | xyzzy
|
|
|
|
(4 rows)
|
|
|
|
|
|
|
|
-- utitlity functions currently not supported here
|
|
|
|
CREATE PROCEDURE ptestx()
|
|
|
|
LANGUAGE SQL
|
|
|
|
BEGIN ATOMIC
|
|
|
|
CREATE TABLE x (a int);
|
|
|
|
END;
|
|
|
|
ERROR: CREATE TABLE is not yet supported in unquoted SQL function body
|
2017-11-30 14:46:13 +01:00
|
|
|
CREATE PROCEDURE ptest2()
|
|
|
|
LANGUAGE SQL
|
|
|
|
AS $$
|
|
|
|
SELECT 5;
|
|
|
|
$$;
|
|
|
|
CALL ptest2();
|
2018-02-21 00:03:31 +01:00
|
|
|
-- nested CALL
|
|
|
|
TRUNCATE cp_test;
|
|
|
|
CREATE PROCEDURE ptest3(y text)
|
|
|
|
LANGUAGE SQL
|
|
|
|
AS $$
|
|
|
|
CALL ptest1(y);
|
|
|
|
CALL ptest1($1);
|
|
|
|
$$;
|
|
|
|
CALL ptest3('b');
|
|
|
|
SELECT * FROM cp_test;
|
|
|
|
a | b
|
|
|
|
---+---
|
|
|
|
1 | b
|
|
|
|
1 | b
|
|
|
|
(2 rows)
|
|
|
|
|
2018-03-14 16:47:21 +01:00
|
|
|
-- output arguments
|
|
|
|
CREATE PROCEDURE ptest4a(INOUT a int, INOUT b int)
|
|
|
|
LANGUAGE SQL
|
|
|
|
AS $$
|
|
|
|
SELECT 1, 2;
|
|
|
|
$$;
|
|
|
|
CALL ptest4a(NULL, NULL);
|
|
|
|
a | b
|
|
|
|
---+---
|
|
|
|
1 | 2
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
CREATE PROCEDURE ptest4b(INOUT b int, INOUT a int)
|
|
|
|
LANGUAGE SQL
|
|
|
|
AS $$
|
|
|
|
CALL ptest4a(a, b); -- error, not supported
|
|
|
|
$$;
|
|
|
|
ERROR: calling procedures with output arguments is not supported in SQL functions
|
|
|
|
CONTEXT: SQL function "ptest4b"
|
|
|
|
DROP PROCEDURE ptest4a;
|
2018-04-13 23:06:28 +02:00
|
|
|
-- named and default parameters
|
|
|
|
CREATE OR REPLACE PROCEDURE ptest5(a int, b text, c int default 100)
|
|
|
|
LANGUAGE SQL
|
|
|
|
AS $$
|
|
|
|
INSERT INTO cp_test VALUES(a, b);
|
|
|
|
INSERT INTO cp_test VALUES(c, b);
|
|
|
|
$$;
|
|
|
|
TRUNCATE cp_test;
|
|
|
|
CALL ptest5(10, 'Hello', 20);
|
|
|
|
CALL ptest5(10, 'Hello');
|
|
|
|
CALL ptest5(10, b => 'Hello');
|
|
|
|
CALL ptest5(b => 'Hello', a => 10);
|
|
|
|
SELECT * FROM cp_test;
|
|
|
|
a | b
|
|
|
|
-----+-------
|
|
|
|
10 | Hello
|
|
|
|
20 | Hello
|
|
|
|
10 | Hello
|
|
|
|
100 | Hello
|
|
|
|
10 | Hello
|
|
|
|
100 | Hello
|
|
|
|
10 | Hello
|
|
|
|
100 | Hello
|
|
|
|
(8 rows)
|
|
|
|
|
2018-07-06 22:27:42 +02:00
|
|
|
-- polymorphic types
|
|
|
|
CREATE PROCEDURE ptest6(a int, b anyelement)
|
|
|
|
LANGUAGE SQL
|
|
|
|
AS $$
|
|
|
|
SELECT NULL::int;
|
|
|
|
$$;
|
|
|
|
CALL ptest6(1, 2);
|
2019-02-05 15:08:53 +01:00
|
|
|
-- collation assignment
|
|
|
|
CREATE PROCEDURE ptest7(a text, b text)
|
|
|
|
LANGUAGE SQL
|
|
|
|
AS $$
|
|
|
|
SELECT a = b;
|
|
|
|
$$;
|
|
|
|
CALL ptest7(least('a', 'b'), 'a');
|
2021-04-07 21:30:08 +02:00
|
|
|
-- empty body
|
|
|
|
CREATE PROCEDURE ptest8(x text)
|
|
|
|
BEGIN ATOMIC
|
|
|
|
END;
|
|
|
|
\df ptest8
|
|
|
|
List of functions
|
|
|
|
Schema | Name | Result data type | Argument data types | Type
|
|
|
|
--------+--------+------------------+---------------------+------
|
Reconsider the handling of procedure OUT parameters.
Commit 2453ea142 redefined pg_proc.proargtypes to include the types of
OUT parameters, for procedures only. While that had some advantages
for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty
disastrous from a number of other perspectives. Notably, since the
primary key of pg_proc is name + proargtypes, this made it possible to
have multiple procedures with identical names + input arguments and
differing output argument types. That would make it impossible to call
any one of the procedures by writing just NULL (or "?", or any other
data-type-free notation) for the output argument(s). The change also
seems likely to cause grave confusion for client applications that
examine pg_proc and expect the traditional definition of proargtypes.
Hence, revert the definition of proargtypes to what it was, and
undo a number of complications that had been added to support that.
To support the SQL-spec behavior of DROP PROCEDURE, when there are
no argmode markers in the command's parameter list, we perform the
lookup both ways (that is, matching against both proargtypes and
proallargtypes), succeeding if we get just one unique match.
In principle this could result in ambiguous-function failures
that would not happen when using only one of the two rules.
However, overloading of procedure names is thought to be a pretty
rare usage, so this shouldn't cause many problems in practice.
Postgres-specific code such as pg_dump can defend against any
possibility of such failures by being careful to specify argmodes
for all procedure arguments.
This also fixes a few other bugs in the area of CALL statements
with named parameters, and improves the documentation a little.
catversion bump forced because the representation of procedures
with OUT arguments changes.
Discussion: https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us
2021-06-10 23:11:36 +02:00
|
|
|
public | ptest8 | | IN x text | proc
|
2021-04-07 21:30:08 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT pg_get_functiondef('ptest8'::regproc);
|
Reconsider the handling of procedure OUT parameters.
Commit 2453ea142 redefined pg_proc.proargtypes to include the types of
OUT parameters, for procedures only. While that had some advantages
for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty
disastrous from a number of other perspectives. Notably, since the
primary key of pg_proc is name + proargtypes, this made it possible to
have multiple procedures with identical names + input arguments and
differing output argument types. That would make it impossible to call
any one of the procedures by writing just NULL (or "?", or any other
data-type-free notation) for the output argument(s). The change also
seems likely to cause grave confusion for client applications that
examine pg_proc and expect the traditional definition of proargtypes.
Hence, revert the definition of proargtypes to what it was, and
undo a number of complications that had been added to support that.
To support the SQL-spec behavior of DROP PROCEDURE, when there are
no argmode markers in the command's parameter list, we perform the
lookup both ways (that is, matching against both proargtypes and
proallargtypes), succeeding if we get just one unique match.
In principle this could result in ambiguous-function failures
that would not happen when using only one of the two rules.
However, overloading of procedure names is thought to be a pretty
rare usage, so this shouldn't cause many problems in practice.
Postgres-specific code such as pg_dump can defend against any
possibility of such failures by being careful to specify argmodes
for all procedure arguments.
This also fixes a few other bugs in the area of CALL statements
with named parameters, and improves the documentation a little.
catversion bump forced because the representation of procedures
with OUT arguments changes.
Discussion: https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us
2021-06-10 23:11:36 +02:00
|
|
|
pg_get_functiondef
|
|
|
|
------------------------------------------------------
|
|
|
|
CREATE OR REPLACE PROCEDURE public.ptest8(IN x text)+
|
|
|
|
LANGUAGE sql +
|
|
|
|
BEGIN ATOMIC +
|
|
|
|
END +
|
2021-04-07 21:30:08 +02:00
|
|
|
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
CALL ptest8('');
|
2020-10-05 09:09:09 +02:00
|
|
|
-- OUT parameters
|
|
|
|
CREATE PROCEDURE ptest9(OUT a int)
|
|
|
|
LANGUAGE SQL
|
|
|
|
AS $$
|
|
|
|
INSERT INTO cp_test VALUES (1, 'a');
|
|
|
|
SELECT 1;
|
|
|
|
$$;
|
Reconsider the handling of procedure OUT parameters.
Commit 2453ea142 redefined pg_proc.proargtypes to include the types of
OUT parameters, for procedures only. While that had some advantages
for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty
disastrous from a number of other perspectives. Notably, since the
primary key of pg_proc is name + proargtypes, this made it possible to
have multiple procedures with identical names + input arguments and
differing output argument types. That would make it impossible to call
any one of the procedures by writing just NULL (or "?", or any other
data-type-free notation) for the output argument(s). The change also
seems likely to cause grave confusion for client applications that
examine pg_proc and expect the traditional definition of proargtypes.
Hence, revert the definition of proargtypes to what it was, and
undo a number of complications that had been added to support that.
To support the SQL-spec behavior of DROP PROCEDURE, when there are
no argmode markers in the command's parameter list, we perform the
lookup both ways (that is, matching against both proargtypes and
proallargtypes), succeeding if we get just one unique match.
In principle this could result in ambiguous-function failures
that would not happen when using only one of the two rules.
However, overloading of procedure names is thought to be a pretty
rare usage, so this shouldn't cause many problems in practice.
Postgres-specific code such as pg_dump can defend against any
possibility of such failures by being careful to specify argmodes
for all procedure arguments.
This also fixes a few other bugs in the area of CALL statements
with named parameters, and improves the documentation a little.
catversion bump forced because the representation of procedures
with OUT arguments changes.
Discussion: https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us
2021-06-10 23:11:36 +02:00
|
|
|
-- standard way to do a call:
|
2020-10-05 09:09:09 +02:00
|
|
|
CALL ptest9(NULL);
|
|
|
|
a
|
|
|
|
---
|
|
|
|
1
|
|
|
|
(1 row)
|
|
|
|
|
Reconsider the handling of procedure OUT parameters.
Commit 2453ea142 redefined pg_proc.proargtypes to include the types of
OUT parameters, for procedures only. While that had some advantages
for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty
disastrous from a number of other perspectives. Notably, since the
primary key of pg_proc is name + proargtypes, this made it possible to
have multiple procedures with identical names + input arguments and
differing output argument types. That would make it impossible to call
any one of the procedures by writing just NULL (or "?", or any other
data-type-free notation) for the output argument(s). The change also
seems likely to cause grave confusion for client applications that
examine pg_proc and expect the traditional definition of proargtypes.
Hence, revert the definition of proargtypes to what it was, and
undo a number of complications that had been added to support that.
To support the SQL-spec behavior of DROP PROCEDURE, when there are
no argmode markers in the command's parameter list, we perform the
lookup both ways (that is, matching against both proargtypes and
proallargtypes), succeeding if we get just one unique match.
In principle this could result in ambiguous-function failures
that would not happen when using only one of the two rules.
However, overloading of procedure names is thought to be a pretty
rare usage, so this shouldn't cause many problems in practice.
Postgres-specific code such as pg_dump can defend against any
possibility of such failures by being careful to specify argmodes
for all procedure arguments.
This also fixes a few other bugs in the area of CALL statements
with named parameters, and improves the documentation a little.
catversion bump forced because the representation of procedures
with OUT arguments changes.
Discussion: https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us
2021-06-10 23:11:36 +02:00
|
|
|
-- you can write an expression, but it's not evaluated
|
|
|
|
CALL ptest9(1/0); -- no error
|
|
|
|
a
|
|
|
|
---
|
|
|
|
1
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- ... and it had better match the type of the parameter
|
|
|
|
CALL ptest9(1./0.); -- error
|
|
|
|
ERROR: procedure ptest9(numeric) does not exist
|
|
|
|
LINE 1: CALL ptest9(1./0.);
|
|
|
|
^
|
|
|
|
HINT: No procedure matches the given name and argument types. You might need to add explicit type casts.
|
|
|
|
-- check named-parameter matching
|
|
|
|
CREATE PROCEDURE ptest10(OUT a int, IN b int, IN c int)
|
|
|
|
LANGUAGE SQL AS $$ SELECT b - c $$;
|
|
|
|
CALL ptest10(null, 7, 4);
|
|
|
|
a
|
|
|
|
---
|
|
|
|
3
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
CALL ptest10(a => null, b => 8, c => 2);
|
|
|
|
a
|
|
|
|
---
|
|
|
|
6
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
CALL ptest10(null, 7, c => 2);
|
|
|
|
a
|
|
|
|
---
|
|
|
|
5
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
CALL ptest10(null, c => 4, b => 11);
|
|
|
|
a
|
|
|
|
---
|
|
|
|
7
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
CALL ptest10(b => 8, c => 2, a => 0);
|
|
|
|
a
|
|
|
|
---
|
|
|
|
6
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
CREATE PROCEDURE ptest11(a OUT int, VARIADIC b int[]) LANGUAGE SQL
|
|
|
|
AS $$ SELECT b[1] + b[2] $$;
|
|
|
|
CALL ptest11(null, 11, 12, 13);
|
|
|
|
a
|
|
|
|
----
|
|
|
|
23
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- check resolution of ambiguous DROP commands
|
|
|
|
CREATE PROCEDURE ptest10(IN a int, IN b int, IN c int)
|
|
|
|
LANGUAGE SQL AS $$ SELECT a + b - c $$;
|
|
|
|
\df ptest10
|
|
|
|
List of functions
|
|
|
|
Schema | Name | Result data type | Argument data types | Type
|
|
|
|
--------+---------+------------------+-------------------------------------------+------
|
|
|
|
public | ptest10 | | IN a integer, IN b integer, IN c integer | proc
|
|
|
|
public | ptest10 | | OUT a integer, IN b integer, IN c integer | proc
|
|
|
|
(2 rows)
|
|
|
|
|
|
|
|
drop procedure ptest10; -- fail
|
|
|
|
ERROR: procedure name "ptest10" is not unique
|
|
|
|
HINT: Specify the argument list to select the procedure unambiguously.
|
|
|
|
drop procedure ptest10(int, int, int); -- fail
|
|
|
|
ERROR: procedure name "ptest10" is not unique
|
|
|
|
begin;
|
|
|
|
drop procedure ptest10(out int, int, int);
|
|
|
|
\df ptest10
|
|
|
|
List of functions
|
|
|
|
Schema | Name | Result data type | Argument data types | Type
|
|
|
|
--------+---------+------------------+------------------------------------------+------
|
|
|
|
public | ptest10 | | IN a integer, IN b integer, IN c integer | proc
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
drop procedure ptest10(int, int, int); -- now this would work
|
|
|
|
rollback;
|
|
|
|
begin;
|
|
|
|
drop procedure ptest10(in int, int, int);
|
|
|
|
\df ptest10
|
|
|
|
List of functions
|
|
|
|
Schema | Name | Result data type | Argument data types | Type
|
|
|
|
--------+---------+------------------+-------------------------------------------+------
|
|
|
|
public | ptest10 | | OUT a integer, IN b integer, IN c integer | proc
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
drop procedure ptest10(int, int, int); -- now this would work
|
|
|
|
rollback;
|
2017-11-30 14:46:13 +01:00
|
|
|
-- various error cases
|
2017-12-13 16:37:48 +01:00
|
|
|
CALL version(); -- error: not a procedure
|
|
|
|
ERROR: version() is not a procedure
|
|
|
|
LINE 1: CALL version();
|
|
|
|
^
|
|
|
|
HINT: To call a function, use SELECT.
|
|
|
|
CALL sum(1); -- error: not a procedure
|
|
|
|
ERROR: sum(integer) is not a procedure
|
|
|
|
LINE 1: CALL sum(1);
|
|
|
|
^
|
2018-06-16 20:10:17 +02:00
|
|
|
HINT: To call a function, use SELECT.
|
2017-11-30 14:46:13 +01:00
|
|
|
CREATE PROCEDURE ptestx() LANGUAGE SQL WINDOW AS $$ INSERT INTO cp_test VALUES (1, 'a') $$;
|
|
|
|
ERROR: invalid attribute in procedure definition
|
|
|
|
LINE 1: CREATE PROCEDURE ptestx() LANGUAGE SQL WINDOW AS $$ INSERT I...
|
|
|
|
^
|
|
|
|
CREATE PROCEDURE ptestx() LANGUAGE SQL STRICT AS $$ INSERT INTO cp_test VALUES (1, 'a') $$;
|
|
|
|
ERROR: invalid attribute in procedure definition
|
|
|
|
LINE 1: CREATE PROCEDURE ptestx() LANGUAGE SQL STRICT AS $$ INSERT I...
|
|
|
|
^
|
Reconsider the handling of procedure OUT parameters.
Commit 2453ea142 redefined pg_proc.proargtypes to include the types of
OUT parameters, for procedures only. While that had some advantages
for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty
disastrous from a number of other perspectives. Notably, since the
primary key of pg_proc is name + proargtypes, this made it possible to
have multiple procedures with identical names + input arguments and
differing output argument types. That would make it impossible to call
any one of the procedures by writing just NULL (or "?", or any other
data-type-free notation) for the output argument(s). The change also
seems likely to cause grave confusion for client applications that
examine pg_proc and expect the traditional definition of proargtypes.
Hence, revert the definition of proargtypes to what it was, and
undo a number of complications that had been added to support that.
To support the SQL-spec behavior of DROP PROCEDURE, when there are
no argmode markers in the command's parameter list, we perform the
lookup both ways (that is, matching against both proargtypes and
proallargtypes), succeeding if we get just one unique match.
In principle this could result in ambiguous-function failures
that would not happen when using only one of the two rules.
However, overloading of procedure names is thought to be a pretty
rare usage, so this shouldn't cause many problems in practice.
Postgres-specific code such as pg_dump can defend against any
possibility of such failures by being careful to specify argmodes
for all procedure arguments.
This also fixes a few other bugs in the area of CALL statements
with named parameters, and improves the documentation a little.
catversion bump forced because the representation of procedures
with OUT arguments changes.
Discussion: https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us
2021-06-10 23:11:36 +02:00
|
|
|
CREATE PROCEDURE ptestx(a VARIADIC int[], b OUT int) LANGUAGE SQL
|
|
|
|
AS $$ SELECT a[1] $$;
|
|
|
|
ERROR: VARIADIC parameter must be the last parameter
|
|
|
|
CREATE PROCEDURE ptestx(a int DEFAULT 42, b OUT int) LANGUAGE SQL
|
|
|
|
AS $$ SELECT a $$;
|
|
|
|
ERROR: procedure OUT parameters cannot appear after one with a default value
|
2017-11-30 14:46:13 +01:00
|
|
|
ALTER PROCEDURE ptest1(text) STRICT;
|
|
|
|
ERROR: invalid attribute in procedure definition
|
|
|
|
LINE 1: ALTER PROCEDURE ptest1(text) STRICT;
|
|
|
|
^
|
|
|
|
ALTER FUNCTION ptest1(text) VOLATILE; -- error: not a function
|
|
|
|
ERROR: ptest1(text) is not a function
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
ALTER PROCEDURE cp_testfunc1(int) VOLATILE; -- error: not a procedure
|
|
|
|
ERROR: cp_testfunc1(integer) is not a procedure
|
2017-11-30 14:46:13 +01:00
|
|
|
ALTER PROCEDURE nonexistent() VOLATILE;
|
|
|
|
ERROR: procedure nonexistent() does not exist
|
|
|
|
DROP FUNCTION ptest1(text); -- error: not a function
|
|
|
|
ERROR: ptest1(text) is not a function
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
DROP PROCEDURE cp_testfunc1(int); -- error: not a procedure
|
|
|
|
ERROR: cp_testfunc1(integer) is not a procedure
|
2017-11-30 14:46:13 +01:00
|
|
|
DROP PROCEDURE nonexistent();
|
|
|
|
ERROR: procedure nonexistent() does not exist
|
|
|
|
-- privileges
|
2018-03-15 19:00:31 +01:00
|
|
|
CREATE USER regress_cp_user1;
|
|
|
|
GRANT INSERT ON cp_test TO regress_cp_user1;
|
2017-11-30 14:46:13 +01:00
|
|
|
REVOKE EXECUTE ON PROCEDURE ptest1(text) FROM PUBLIC;
|
2018-03-15 19:00:31 +01:00
|
|
|
SET ROLE regress_cp_user1;
|
2017-11-30 14:46:13 +01:00
|
|
|
CALL ptest1('a'); -- error
|
2017-12-02 15:26:34 +01:00
|
|
|
ERROR: permission denied for procedure ptest1
|
2017-11-30 14:46:13 +01:00
|
|
|
RESET ROLE;
|
2018-03-15 19:00:31 +01:00
|
|
|
GRANT EXECUTE ON PROCEDURE ptest1(text) TO regress_cp_user1;
|
|
|
|
SET ROLE regress_cp_user1;
|
2017-11-30 14:46:13 +01:00
|
|
|
CALL ptest1('a'); -- ok
|
|
|
|
RESET ROLE;
|
|
|
|
-- ROUTINE syntax
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
ALTER ROUTINE cp_testfunc1(int) RENAME TO cp_testfunc1a;
|
|
|
|
ALTER ROUTINE cp_testfunc1a RENAME TO cp_testfunc1;
|
2017-11-30 14:46:13 +01:00
|
|
|
ALTER ROUTINE ptest1(text) RENAME TO ptest1a;
|
|
|
|
ALTER ROUTINE ptest1a RENAME TO ptest1;
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
DROP ROUTINE cp_testfunc1(int);
|
2017-11-30 14:46:13 +01:00
|
|
|
-- cleanup
|
|
|
|
DROP PROCEDURE ptest1;
|
2021-04-07 21:30:08 +02:00
|
|
|
DROP PROCEDURE ptest1s;
|
2017-11-30 14:46:13 +01:00
|
|
|
DROP PROCEDURE ptest2;
|
|
|
|
DROP TABLE cp_test;
|
2018-03-15 19:00:31 +01:00
|
|
|
DROP USER regress_cp_user1;
|