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 по дате отправления: