Re: pg_upgrade (12->14) fails on aggregate
От | Andrey Borodin |
---|---|
Тема | Re: pg_upgrade (12->14) fails on aggregate |
Дата | |
Msg-id | AF678A5C-6ED7-4144-B264-68FEF31ED3A8@yandex-team.ru обсуждение исходный текст |
Ответ на | Re: pg_upgrade (12->14) fails on aggregate (Justin Pryzby <pryzby@telsasoft.com>) |
Ответы |
Re: pg_upgrade (12->14) fails on aggregate
|
Список | 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 по дате отправления: