The range of OIDs for system objects is 1 to 16383.
In PostgreSQL include files, server/access/transam.h has this presentation of how OIDs are assigned, which might help:
/* ----------
* Object ID (OID) zero is InvalidOid.
*
* OIDs 1-9999 are reserved for manual assignment (see .dat files in
* src/include/catalog/). Of these, 8000-9999 are reserved for
* development purposes (such as in-progress patches and forks);
* they should not appear in released versions.
*
* OIDs 10000-11999 are reserved for assignment by genbki.pl, for use
* when the .dat files in src/include/catalog/ do not specify an OID
* for a catalog entry that requires one. Note that genbki.pl assigns
* these OIDs independently in each catalog, so they're not guaranteed
* to be globally unique. Furthermore, the bootstrap backend and
* initdb's post-bootstrap processing can also assign OIDs in this range.
* The normal OID-generation logic takes care of any OID conflicts that
* might arise from that.
*
* OIDs 12000-16383 are reserved for unpinned objects created by initdb's
* post-bootstrap processing. initdb forces the OID generator up to
* 12000 as soon as it's made the pinned objects it's responsible for.
*
* OIDs beginning at 16384 are assigned from the OID generator
* during normal multiuser operation. (We force the generator up to
* 16384 as soon as we are in normal operation.)
*
* The choices of 8000, 10000 and 12000 are completely arbitrary, and can be
* moved if we run low on OIDs in any category. Changing the macros below,
* and updating relevant documentation (see bki.sgml and RELEASE_CHANGES),
* should be sufficient to do this. Moving the 16384 boundary between
* initdb-assigned OIDs and user-defined objects would be substantially
* more painful, however, since some user-defined OIDs will appear in
* on-disk data; such a change would probably break pg_upgrade.
*
* NOTE: if the OID generator wraps around, we skip over OIDs 0-16383
* and resume with 16384. This minimizes the odds of OID conflict, by not
* reassigning OIDs that might have been assigned during initdb. Critically,
* it also ensures that no user-created object will be considered pinned.
* ----------
*/
#define FirstGenbkiObjectId 10000
#define FirstUnpinnedObjectId 12000
#define FirstNormalObjectId 16384
If you needed your own OIDs in the system range for some reason, I think that would fall under the "fork" category, so in the 8000-9999 range.
Q: Also, are OIDs being phased out of PostgreSQL
No, but the OID columns have been demoted to "normal" columns in Postgres 12, as opposed to system columns. There have been a gradual process in the evolution of Postgres to normalize the OIDs as normal per-table numeric primary keys, instead of the "globally unique primary key" that they were in the original design. See for instance the blog post OIDs demoted to normal columns: a glance at the past about this evolution. This is not to phase out OIDs but to ensure that they don't get in the way of progress.
Q: As an example, pg_roles table seems to use OIDs of four digits or less
for objects created during installation or for patches
pg_roles itself is not a table, it's a view . One of its columns is named oid, and its value comes from pg_authid.oid. It's the primary key of pg_authid. There's really nothing in that that has much to do with installation, except that the system role created (generally postgres) has an oid value below 16384, and the roles created post-installation with CREATE USER or CREATE ROLE will have oid values above 16384.
