Re: removing datlastsysoid

Поиск
Список
Период
Сортировка
От David Steele
Тема Re: removing datlastsysoid
Дата
Msg-id a6ab2324-9d47-45e6-e030-05ea07447007@pgmasters.net
обсуждение исходный текст
Ответ на Re: removing datlastsysoid  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: removing datlastsysoid  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Список pgsql-hackers

On 5/16/22 10:26 AM, Tom Lane wrote:
> Dave Page <dpage@pgadmin.org> writes:
>> On Mon, 16 May 2022 at 15:06, David Steele <david@pgmasters.net> wrote:
>>> Out solution was to use the constant:
>>>
>>> #define FirstNormalObjectId             16384
>>>
>>> And treat anything below that as a system oid. This constant has not
>>> changed in a very long time (if ever) but we added it to our list of
>>> constants to recheck with each release.
> 
>> Yes, that seems reasonable. Changing that value would very likely break
>> pg_upgrade I can imagine, so I suspect it'll stay as it is for a while
>> longer.
> 
> Yeah, raising that would be extremely painful for pg_upgrade.
> 
> I think that when we approach the point where the system OID range
> is saturated, we'll give up the principle of system OIDs being
> globally unique instead of doing that.  There's no fundamental
> reason why unique-per-catalog wouldn't be good enough, and letting
> that be the standard would give us many more years of breathing room.
I'm in favor of global IDs since they help prevent incorrect joins, but 
agree that what you propose would likely be the least painful solution.

Regards,
-- 
-David
david@pgmasters.net



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: removing datlastsysoid
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: JSON Functions and Operators Docs for v15