Re: pg_upgrade (12->14) fails on aggregate
От | Andrey Borodin |
---|---|
Тема | Re: pg_upgrade (12->14) fails on aggregate |
Дата | |
Msg-id | 33211367-6CAF-4B09-AA0E-020C62FAD8EF@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 23 Jun 2022, at 04:58, Justin Pryzby <pryzby@telsasoft.com> wrote: > > On Fri, Jun 17, 2022 at 10:14:13AM -0400, Tom Lane wrote: >> Robert Haas <robertmhaas@gmail.com> writes: >>> On Thu, Jun 16, 2022 at 10:01 PM Justin Pryzby <pryzby@telsasoft.com> wrote: >>>> To me, oid>=16384 seems more hard-wired than namespace!='pg_catalog'. >> >>> Extensions can be installed into pg_catalog, but they can't get >>> low-numbered OIDs. >> >> Exactly. (To be clear, I had in mind writing something involving >> FirstNormalObjectId, not that you should put literal "16384" in the >> code.) > > Actually, 16384 is already used in two other places in check.c, so ... Yes, but it's a third copy of the comment ("* The query below hardcodes FirstNormalObjectId as 16384 rather than") acrossthe file. Also, we can return slightly more information about found objects. For example, operator will look like "operator: ||". Atleast we can get nspname and oid. And, maybe return type for aggregator and leftarg\rightarg types for operator? BTW comment /* Before v11, used proisagg=true, and afterwards uses prokind='a' */ seems interesting, but irrelevant. We joinwith pg_aggregate anyway. Thanks! Best regards, Andrey Borodin.
В списке pgsql-hackers по дате отправления: