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  (Justin Pryzby <pryzby@telsasoft.com>)
Список 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 по дате отправления:

Предыдущее
От: Leif Harald Karlsen
Дата:
Сообщение: Re: Implement hook for self-join simplification
Следующее
От: Jacob Champion
Дата:
Сообщение: Re: [PoC] Let libpq reject unexpected authentication requests