Re: Replacing pg_depend PIN entries with a fixed range check

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Replacing pg_depend PIN entries with a fixed range check
Дата
Msg-id 3562349.1626291250@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Replacing pg_depend PIN entries with a fixed range check  (John Naylor <john.naylor@enterprisedb.com>)
Ответы Re: Replacing pg_depend PIN entries with a fixed range check
Список pgsql-hackers
John Naylor <john.naylor@enterprisedb.com> writes:
> On Thu, May 27, 2021 at 6:53 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Attached is a rebase over a4390abec.

> Looks good to me overall, I just had a couple questions/comments:

Thanks for looking!

> isObjectPinned and isSharedObjectPinned are now thin wrappers around
> IsPinnedObject. Is keeping those functions a matter of future-proofing in
> case something needs to be handled differently someday, or reducing
> unnecessary code churn?

Yeah, it was mostly a matter of reducing code churn.  We could probably
drop isSharedObjectPinned altogether, but isObjectPinned seems to have
some notational value in providing an API that takes an ObjectAddress.

> setup_depend now doesn't really need to execute any SQL (unless third-party
> forks have extra steps here?), and could be replaced with a direct call
> to StopGeneratingPinnedObjectIds. That's a bit more self-documenting, and
> that would allow shortening this comment:

Hm, I'm not following?  setup_depend runs in initdb, that is on the
client side.  It can't invoke backend-internal functions any other
way than via SQL, AFAICS.

            regards, tom lane



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

Предыдущее
От: "David G. Johnston"
Дата:
Сообщение: Re: pg_upgrade does not upgrade pg_stat_statements properly
Следующее
От: Ibrar Ahmed
Дата:
Сообщение: Re: [PATCH] Partial foreign key updates in referential integrity triggers