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

From Andrey Borodin
Subject Re: pg_upgrade (12->14) fails on aggregate
Date
Msg-id AF678A5C-6ED7-4144-B264-68FEF31ED3A8@yandex-team.ru
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

> On 25 Jun 2022, at 01:28, Justin Pryzby <pryzby@telsasoft.com> wrote:
>
> But what I wrote already shows what you want.
Just tested that, you are right. My version was printing name, I didn't know regproc prints so nice definition.

>  this is my latest.
> <0001-WIP-pg_upgrade-check-detect-old-polymorphics-from-pr.patch>

Let's rename "databases_with_old_polymorphics.txt" to somthing like "old_polymorphics.txt" or maybe even
"incompatible_polymorphics_usage.txt"?
I think you will come up with a better name, my point is here everythin is in "databases", and "old" doesn't describe
essenceof the problem. 

Also, let's check that oid of used functions belong to system catalog (<16384)? We don't care about user-defined
functionswith the same name. 

And, probably, we can do this unconditionally:
if (old_cluster.major_version >= 9500)
        appendPQExpBufferStr(&old_polymorphics,
Nothing bad will happen if we blacklist usage of nonexistent functions. I see there's a lot of code to have a dynamic
list,if you think this exclusion for pre-9.5 is justified - OK, from my POV we can keep this code. 

These comment is unneeded too:
// "AND aggtranstype='anyarray'::regtype

Thank you!

Best regards, Andrey Borodin.





pgsql-hackers by date:

Previous
From: Dean Rasheed
Date:
Subject: Re: Core dump in range_table_mutator()
Next
From: Robert Haas
Date:
Subject: Re: making relfilenodes 56 bits