Re: Replacing pg_depend PIN entries with a fixed range check

Andres Freund <andres(at)anarazel(dot)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