Re: Replacing pg_depend PIN entries with a fixed range check - Mailing list pgsql-hackers

From John Naylor
Subject Re: Replacing pg_depend PIN entries with a fixed range check
Date
Msg-id CAFBsxsG+bhcN1pCiEf_trU7w31AbN+OpdGZmKUrNaN3ZJr8qoQ@mail.gmail.com
Whole thread Raw
In response to Re: Replacing pg_depend PIN entries with a fixed range check  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Replacing pg_depend PIN entries with a fixed range check  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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:

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?

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:

 /*
* Note that no objects created after setup_depend() will be "pinned".
* They are all droppable at the whim of the DBA.
*/

--
John Naylor
EDB: http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Ranier Vilela
Date:
Subject: Re: [PATCH] Use optimized single-datum tuplesort in ExecSort
Next
From: Alvaro Herrera
Date:
Subject: Re: CREATE TABLE .. PARTITION OF fails to preserve tgenabled for inherited row triggers