The following simple script:
CREATE TABLE test(i INT PRIMARY KEY);
CREATE FUNCTION func2(i INT) RETURNS INT IMMUTABLE LANGUAGE SQL
AS 'SELECT $1';
CREATE FUNCTION func1(c INT) RETURNS INT IMMUTABLE LANGUAGE SQL
AS 'SELECT func2($1)';
CREATE INDEX ON test(func1(i));
makes pg_upgrade choke on the database:
Analyzing all rows in the new cluster ok
Freezing all rows in the new cluster ok
Deleting files from new pg_xact ok
Copying old pg_xact to new server ok
Setting next transaction ID and epoch for new cluster ok
Deleting files from new pg_multixact/offsets ok
Copying old pg_multixact/offsets to new server ok
Deleting files from new pg_multixact/members ok
Copying old pg_multixact/members to new server ok
Setting next multixact ID and offset for new cluster ok
Resetting WAL archives ok
Setting frozenxid and minmxid counters in new cluster ok
Restoring global objects in the new cluster ok
Restoring database schemas in the new cluster
Consult the last few lines of "pg_upgrade_dump_12717.log" for
the probable cause of the failure.
pg_restore: creating INDEX "public.test_func1_idx"
pg_restore: while PROCESSING TOC:
pg_restore: from TOC entry 2089; 1259 16391 INDEX test_func1_idx postgres
pg_restore: error: could not execute query: ERROR: function func2(integer)
does not exist
LINE 1: SELECT func2($1)
HINT: No function matches the given name and argument types. You might need
to add explicit type casts.
QUERY: SELECT func2($1)
CONTEXT: SQL function "func1" during inlining
-- For binary upgrade, must preserve pg_class oids
CREATE INDEX "test_func1_idx" ON "public"."test" USING "btree"
Re: BUG #16137: pg_upgrade fails with an index over nesting function
PG Bug reporting form <[hidden email]> writes:
> CREATE TABLE test(i INT PRIMARY KEY);
> CREATE FUNCTION func2(i INT) RETURNS INT IMMUTABLE LANGUAGE SQL
> AS 'SELECT $1';
> CREATE FUNCTION func1(c INT) RETURNS INT IMMUTABLE LANGUAGE SQL
> AS 'SELECT func2($1)';
This function is unreliable for lack of schema qualification.
I tend to agree that it'd be nice if pg_upgrade wouldn't be
so picky about that, but we haven't really found a way that
doesn't create security issues (cf CVE-2018-1058).