Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables
В списке pgsql-hackers по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables |
| Дата | |
| Msg-id | 21845.1249527647@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables (Andrew Dunstan <andrew@dunslane.net>) |
| Список | pgsql-hackers |
Andrew Dunstan <andrew@dunslane.net> writes:
> Is there any danger that an oid used in, say, pg_enum in the old version
> will be used in the catalog bootstrap in the new version?
No. All initdb-assigned OIDs are less than 16K, and we never assign
such an OID post-initdb (not even when wrapping around). We might get
into trouble if we ever run out of OIDs below 16K, but I don't foresee
that happening anytime soon.
Also, the design I sketched depends on the fact that it doesn't matter
if, say, a pg_proc row gets an OID that we also need to use in pg_enum.
We only need OID uniqueness within each specific catalog. So we don't
need to control the OID assignments in catalogs other than the three
we are interested in.
regards, tom lane
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера