Re: Replacing pg_depend PIN entries with a fixed range check

Andres Freund <andres@anarazel.de> writes:
> Hm, maybe we ought to swap template0 and template1 instead? I.e. have
> template0 be in pg_database.dat and thus get a pinned oid, and then
> create template1, postgres etc from that?

No, *neither* of them are pinned, and we don't want them to be.
It's something of a historical artifact that template1 has a low OID.

>> +    /*
>> +     * Large objects are never pinned.  We need this special case because
>> +     * their OIDs can be user-assigned.
>> +     */
>> +    if (classId == LargeObjectRelationId)
>> +        return false;

> Huh, shouldn't we reject that when creating them?

We've got regression tests that create blobs with small OIDs :-(.
We could change those tests of course, but they're pretty ancient
and I'm hesitant to move those goal posts.

> I guess you didn't because of dump/restore concerns?

That too.

In short, I'm really skeptical of changing any of these pin-or-not
decisions to save one or two comparisons in IsPinnedObject.  That
function is already orders of magnitude faster than what it replaces;
we don't need to sweat over making it faster yet.

            regards, tom lane