Re: programmatically retrieve details of a custom Postgres type
От | Tom Lane |
---|---|
Тема | Re: programmatically retrieve details of a custom Postgres type |
Дата | |
Msg-id | 457233.1668141032@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: programmatically retrieve details of a custom Postgres type (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: programmatically retrieve details of a custom Postgres type
|
Список | 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
В списке pgsql-general по дате отправления: