Hi,
Some catalog oid values originate from other catalogs,
such as pg_aggregate.aggfnoid -> pg_proc.oid
or pg_attribute.attrelid -> pg_class.oid.
For such oid values, the foreign catalog is the regclass
which should be passed as the first argument to
all the functions taking (classid oid, objid oid, objsubid integer)
as input, i.e. pg_describe_object(), pg_identify_object() and
pg_identify_object_as_address().
All oids values in all catalogs,
can be used with these functions,
as long as the correct regclass is passed as the first argument,
*except* pg_enum.oid.
(This is not a problem for pg_enum.enumtypid,
its regclass is 'pg_type' and works fine.)
I would have expected the regclass to be 'pg_enum'::regclass,
since there is no foreign key on pg_enum.oid.
In a way, pg_enum is similar to pg_attribute,
pg_enum.enumtypid -> pg_type.oid
reminds me of
pg_attribute.attrelid -> pg_class.oid
But pg_enum has its own oid column as primary key,
whereas in pg_attribute we only have a multi-column primary key (attrelid, attnum).
Is this a bug? I.e. should we add support to deal with pg_enum.oid?
Or is this by design?
If so, wouldn't it be good to mention this corner-case
somewhere in the documentation for pg_identify_object_as_address() et al?
That is, to explain these functions works for almost all oid values, except pg_enum.oid.
/Joel