Justin Pryzby <pry...@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