Re: automatically assigning catalog toast oids

On 2018-Dec-13, Tom Lane wrote:

> We could take it a bit further and not make the 'p' entries for such
> OIDs in the first place, greatly reducing the size of pg_depend in
> typical installations.  Perhaps that'd confuse clients that look at
> that catalog, though.

The number of 'p' entries in pg_depend is often annoying when manually
querying it.  I support the idea of special-casing such entries.

> Looking at the existing entries, it seems like we'd have to have
> one special case: schema public has OID 2200 but is intentionally
> not pinned.  I wouldn't have a hard time with teaching isObjectPinned
> about that; though if it turns out that many places need to know
> about it, maybe it's not workable.

Why not just move that OID outside the Genbki special range?  I have
seen quite a few installs where schema public was removed and later
re-added.  I've never seen a query hardcode OID 2200, and I'd call one
which does buggy.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services