1
0
mirror of https://github.com/postgres/postgres.git synced 2025-07-05 07:21:24 +03:00

Solve cross-version-upgrade testing problem induced by 1fb57af92.

Renaming varchar_transform to varchar_support had a side effect
I hadn't foreseen: the core regression tests leave around a
transform object that relies on that function, so the name
change breaks cross-version upgrade tests, because the name
used in the older branches doesn't match.

Since the dependency on varchar_transform was chosen with the
aid of a dartboard anyway (it would surely not work as a
language transform support function), fix by just choosing
a different random builtin function with the right signature.
Also add some comments explaining why this isn't horribly unsafe.

I chose to make the same substitution in a couple of other
copied-and-pasted test cases, for consistency, though those
aren't directly contributing to the testing problem.

Per buildfarm.  Back-patch, else it doesn't fix the problem.
This commit is contained in:
Tom Lane
2019-02-09 21:02:06 -05:00
parent 2c83321771
commit 1afcf6aed7
4 changed files with 14 additions and 6 deletions

View File

@ -5,9 +5,11 @@
-- The function FROM SQL should have internal as single argument as well -- The function FROM SQL should have internal as single argument as well
-- as return type. The function TO SQL should have as single argument -- as return type. The function TO SQL should have as single argument
-- internal and as return argument the datatype of the transform done. -- internal and as return argument the datatype of the transform done.
-- pl/plpgsql does not authorize the use of internal as data type. -- We choose some random built-in functions that have the right signature.
-- This won't actually be used, because the SQL function language
-- doesn't implement transforms (there would be no point).
CREATE TRANSFORM FOR int LANGUAGE SQL ( CREATE TRANSFORM FOR int LANGUAGE SQL (
FROM SQL WITH FUNCTION varchar_transform(internal), FROM SQL WITH FUNCTION prsd_lextype(internal),
TO SQL WITH FUNCTION int4recv(internal)); TO SQL WITH FUNCTION int4recv(internal));
NOTICE: DDL test: type simple, tag CREATE TRANSFORM NOTICE: DDL test: type simple, tag CREATE TRANSFORM
DROP TRANSFORM FOR int LANGUAGE SQL; DROP TRANSFORM FOR int LANGUAGE SQL;

View File

@ -6,9 +6,11 @@
-- The function FROM SQL should have internal as single argument as well -- The function FROM SQL should have internal as single argument as well
-- as return type. The function TO SQL should have as single argument -- as return type. The function TO SQL should have as single argument
-- internal and as return argument the datatype of the transform done. -- internal and as return argument the datatype of the transform done.
-- pl/plpgsql does not authorize the use of internal as data type. -- We choose some random built-in functions that have the right signature.
-- This won't actually be used, because the SQL function language
-- doesn't implement transforms (there would be no point).
CREATE TRANSFORM FOR int LANGUAGE SQL ( CREATE TRANSFORM FOR int LANGUAGE SQL (
FROM SQL WITH FUNCTION varchar_transform(internal), FROM SQL WITH FUNCTION prsd_lextype(internal),
TO SQL WITH FUNCTION int4recv(internal)); TO SQL WITH FUNCTION int4recv(internal));
DROP TRANSFORM FOR int LANGUAGE SQL; DROP TRANSFORM FOR int LANGUAGE SQL;

View File

@ -32,8 +32,10 @@ CREATE SERVER "integer" FOREIGN DATA WRAPPER addr_fdw;
CREATE USER MAPPING FOR regtest_addr_user SERVER "integer"; CREATE USER MAPPING FOR regtest_addr_user SERVER "integer";
ALTER DEFAULT PRIVILEGES FOR ROLE regtest_addr_user IN SCHEMA public GRANT ALL ON TABLES TO regtest_addr_user; ALTER DEFAULT PRIVILEGES FOR ROLE regtest_addr_user IN SCHEMA public GRANT ALL ON TABLES TO regtest_addr_user;
ALTER DEFAULT PRIVILEGES FOR ROLE regtest_addr_user REVOKE DELETE ON TABLES FROM regtest_addr_user; ALTER DEFAULT PRIVILEGES FOR ROLE regtest_addr_user REVOKE DELETE ON TABLES FROM regtest_addr_user;
-- this transform would be quite unsafe to leave lying around,
-- except that the SQL language pays no attention to transforms:
CREATE TRANSFORM FOR int LANGUAGE SQL ( CREATE TRANSFORM FOR int LANGUAGE SQL (
FROM SQL WITH FUNCTION varchar_transform(internal), FROM SQL WITH FUNCTION prsd_lextype(internal),
TO SQL WITH FUNCTION int4recv(internal)); TO SQL WITH FUNCTION int4recv(internal));
-- test some error cases -- test some error cases
SELECT pg_get_object_address('stone', '{}', '{}'); SELECT pg_get_object_address('stone', '{}', '{}');

View File

@ -36,8 +36,10 @@ CREATE SERVER "integer" FOREIGN DATA WRAPPER addr_fdw;
CREATE USER MAPPING FOR regtest_addr_user SERVER "integer"; CREATE USER MAPPING FOR regtest_addr_user SERVER "integer";
ALTER DEFAULT PRIVILEGES FOR ROLE regtest_addr_user IN SCHEMA public GRANT ALL ON TABLES TO regtest_addr_user; ALTER DEFAULT PRIVILEGES FOR ROLE regtest_addr_user IN SCHEMA public GRANT ALL ON TABLES TO regtest_addr_user;
ALTER DEFAULT PRIVILEGES FOR ROLE regtest_addr_user REVOKE DELETE ON TABLES FROM regtest_addr_user; ALTER DEFAULT PRIVILEGES FOR ROLE regtest_addr_user REVOKE DELETE ON TABLES FROM regtest_addr_user;
-- this transform would be quite unsafe to leave lying around,
-- except that the SQL language pays no attention to transforms:
CREATE TRANSFORM FOR int LANGUAGE SQL ( CREATE TRANSFORM FOR int LANGUAGE SQL (
FROM SQL WITH FUNCTION varchar_transform(internal), FROM SQL WITH FUNCTION prsd_lextype(internal),
TO SQL WITH FUNCTION int4recv(internal)); TO SQL WITH FUNCTION int4recv(internal));
-- test some error cases -- test some error cases