Re: pg_upgrade (12->14) fails on aggregate - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_upgrade (12->14) fails on aggregate
Date
Msg-id 540147.1655321524@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_upgrade (12->14) fails on aggregate  (Justin Pryzby <pryzby@telsasoft.com>)
Responses Re: pg_upgrade (12->14) fails on aggregate
List pgsql-hackers
Justin Pryzby <pryzby@telsasoft.com> writes:
> But Petr has a point - pg_upgrade should aspire to catch errors in --check,
> rather than starting and then leaving a mess behind for the user to clean up

Agreed; pg_upgrade has historically tried to find problems similar to
this.  However, it's not just aggregates that are at risk.  People
might also have built user-defined plain functions, or operators,
atop these functions.  How far do we want to go in looking?

As for the query, I think it could be simplified quite a bit by
relying on regprocedure literals, that is something like

WHERE ... a.aggtransfn IN
      ('array_append(anyarray,anyelement)'::regprocedure,
       'array_prepend(anyelement,anyarray)'::regprocedure,
       ...)

Not sure if it's necessary to stick explicit "pg_catalog." schema
qualifications into this --- IIRC pg_upgrade runs with restrictive
search_path, so that this would be safe as-is.

Also, I think you need to check aggfinalfn too.

Also, I'd be inclined to reject system-provided objects by checking
for OID >= 16384 rather than hard-wiring assumptions about things
being in pg_catalog or not.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Using PQexecQuery in pipeline mode produces unexpected Close messages
Next
From: Robert Haas
Date:
Subject: Re: better page-level checksums