Re: programmatically retrieve details of a custom Postgres type

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Konstantin Izmailov <pgfizm(at)gmail(dot)com>
Cc: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: programmatically retrieve details of a custom Postgres type
Date: 2022-11-11 04:30:32
Message-ID: 457233.1668141032@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

I wrote:
> For a composite type, pg_type.typrelid links to pg_class and pg_attribute
> entries that work much like a table.

Actually, you could reverse that: for a table, pg_type.typrelid links to
pg_class and pg_attribute entries that work much like a composite type.

For both relations and composite types, there are pg_class and pg_type
entries that (by convention only) have the same names and namespaces.
They cross-link to each other via pg_class.reltype and pg_type.typrelid.
The associated pg_attribute entries have attrelid matching the pg_class
OID. The catalog entries for the two cases are pretty nearly
indistinguishable except for pg_class.relkind. Again, it's only by
convention that we consider that the pg_type entry is primary for a
composite type but pg_class is primary for a relation.

Of course, a relation has some underlying storage (for most relkinds),
and it will likely have associated entries in other catalogs that a
composite type won't. But the core catalog entries are about the same.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Peter Smith 2022-11-11 04:47:24 Re: Support logical replication of DDLs
Previous Message Tom Lane 2022-11-11 04:10:13 Re: programmatically retrieve details of a custom Postgres type