Re: Allowing extensions to find out the OIDs of their member objects

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Allowing extensions to find out the OIDs of their member objects
Дата
Msg-id 20190121091453.GA2520@paquier.xyz
обсуждение исходный текст
Ответ на Allowing extensions to find out the OIDs of their member objects  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Sun, Jan 20, 2019 at 06:50:33PM -0500, Tom Lane wrote:
> A larger issue is whether "hand out some OIDs on-demand" is a
> sustainable strategy.  I think that it is, if we encourage extensions
> to assign fixed OIDs only to objects they really need to.  In thirty-ish
> years of core PG development, we've only used up ~4200 fixed OIDs,
> and a lot of those are for functions that probably don't really need
> fixed OIDs but got one because we give one to every built-in function.
> However, if there's a big land rush to claim large chunks of OIDs,
> we might have a problem.

Hm.  Such things are a bit concerning.  There are many closed and open
extensions, so it looks hard to not create conflicts between multiple
extensions trying to get the same range of OIDs or even the same OIDs
and users willing to combine some of them.  This could mess up the
user experience.
--
Michael

Вложения

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

Предыдущее
От: Amit Langote
Дата:
Сообщение: Re: speeding up planning with partitions
Следующее
От: Fabien COELHO
Дата:
Сообщение: Re: [PATCH] pgbench tap tests fail if the path contains a perlspecial character