On 3/30/21 3:08 PM, Joel Jacobson wrote:
> 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.
>
>
I think the short answer is it's not a bug. In theory we could provide
support for
pg_describe_object('pg_enum'::regclass, myenum, 0)
but what would it return? There is no sane description other than the
enum's label, which you can get far more simply.
Maybe this small break on orthogonality should be noted, if enough
people care, but I doubt we should do anything else.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com