From: | Konstantin Izmailov <pgfizm(at)gmail(dot)com> |
---|---|
To: | |
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 15:33:38 |
Message-ID: | CAAw-MseRgSs-xZyz-n9CsydfG3gWCGBxEeyETkwwiSRavBgfXQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Thank you, Pavel and Tom! It works great!
On Thu, Nov 10, 2022 at 9:30 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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
>
From | Date | Subject | |
---|---|---|---|
Next Message | fernando violante | 2022-11-11 15:42:14 | change Log language |
Previous Message | vignesh C | 2022-11-11 14:39:17 | Re: Support logical replication of DDLs |