Avi Weinberg <AviW@xxxxxxxxx> writes: > I noticed this problem when creating a backup on Postgres 13 and restoring it on Postgres 15. > CREATE FUNCTION sync.show_pg_subscription1() RETURNS SETOF pg_subscription > LANGUAGE sql > AS $$ > SELECT * from pg_subscription; > $$; > The Postgres backup creates the view syntax with " FROM sync.show_pg_subscription1() show_pg_subscription1(oid, subdbid, subname, subowner, subenabled, subconninfo, subslotname, subsynccommit, subpublications);" Yeah. This is intentional: if we don't decompile function calls that way, then other cases break. I'd say the fundamental problem here is that you used the antipattern "SELECT * FROM ...", rather than listing out the columns you want explicitly. Even introductory SQL textbooks warn against doing that in long-lived code. It would actually still have worked if you'd not bothered with the intermediate function, which seems to be adding nothing except execution cost and complication. If you'd just done CREATE VIEW sync.pg_subscription_view1 AS SELECT * FROM pg_subscription; then this would have decompiled as selecting specific columns from pg_subscription, and it would have been quite safe against column additions or reordering in pg_subscription. Having said that, we do reserve the right to actually change existing columns in system catalogs. So you simply cannot expect that code that looks at system catalogs is never going to need to be touched when doing a major version upgrade. regards, tom lane
