Avi Weinberg <AviW@gilat.com> 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