Create composite array types for initdb-created relations.

When we invented arrays of composite types (commit bc8036fc6),
we excluded system catalogs, basically just on the grounds of not
wanting to bloat pg_type.  However, it's definitely inconsistent that
catalogs' composite types can't be put into arrays when others can.
Another problem is that the exclusion is done by checking
IsUnderPostmaster in heap_create_with_catalog, which means that

(1) If a user tries to create a table in single-user mode, it doesn't
get an array type.  That's bad in itself, plus it breaks pg_upgrade.

(2) If someone drops and recreates a system view or information_schema
view (as we occasionally recommend doing), it will now have an array
type where it did not before, making for still more inconsistency.

So this is all pretty messy.  Let's just get rid of the inconsistency
and decree that system-created relations should have array types if
similar user-created ones would, i.e. it only depends on the relkind.
As of HEAD, that means that the initial contents of pg_type grow from
411 rows to 605, which is a lot of growth percentage-wise, but it's
still quite a small catalog compared to others.

Wenjing Zeng, reviewed by Shawn Wang, further hacking by me

Discussion: https://postgr.es/m/761F1389-C6A8-4C15-80CE-950C961F5341@gmail.com
This commit is contained in:
Tom Lane 2020-07-06 14:21:16 -04:00
parent bae9e8a58b
commit f7f70d5e22
3 changed files with 12 additions and 15 deletions

View File

@ -1262,17 +1262,14 @@ heap_create_with_catalog(const char *relname,
new_rel_desc->rd_rel->relrewrite = relrewrite;
/*
* Decide whether to create an array type over the relation's rowtype. We
* do not create any array types for system catalogs (ie, those made
* during initdb). We do not create them where the use of a relation as
* such is an implementation detail: toast tables, sequences and indexes.
* Decide whether to create an array type over the relation's rowtype.
* Array types are made except where the use of a relation as such is an
* implementation detail: toast tables, sequences and indexes.
*/
if (IsUnderPostmaster && (relkind == RELKIND_RELATION ||
relkind == RELKIND_VIEW ||
relkind == RELKIND_MATVIEW ||
relkind == RELKIND_FOREIGN_TABLE ||
relkind == RELKIND_COMPOSITE_TYPE ||
relkind == RELKIND_PARTITIONED_TABLE))
if (!(relkind == RELKIND_SEQUENCE ||
relkind == RELKIND_TOASTVALUE ||
relkind == RELKIND_INDEX ||
relkind == RELKIND_PARTITIONED_INDEX))
new_array_oid = AssignTypeArrayOid();
/*

View File

@ -53,6 +53,6 @@
*/
/* yyyymmddN */
#define CATALOG_VERSION_NO 202006301
#define CATALOG_VERSION_NO 202007061
#endif

View File

@ -113,22 +113,22 @@
# hand-built rowtype entries for bootstrapped catalogs
# NB: OIDs assigned here must match the BKI_ROWTYPE_OID declarations
{ oid => '71',
{ oid => '71', array_type_oid => '210',
typname => 'pg_type', typlen => '-1', typbyval => 'f', typtype => 'c',
typcategory => 'C', typrelid => 'pg_type', typinput => 'record_in',
typoutput => 'record_out', typreceive => 'record_recv',
typsend => 'record_send', typalign => 'd', typstorage => 'x' },
{ oid => '75',
{ oid => '75', array_type_oid => '270',
typname => 'pg_attribute', typlen => '-1', typbyval => 'f', typtype => 'c',
typcategory => 'C', typrelid => 'pg_attribute', typinput => 'record_in',
typoutput => 'record_out', typreceive => 'record_recv',
typsend => 'record_send', typalign => 'd', typstorage => 'x' },
{ oid => '81',
{ oid => '81', array_type_oid => '272',
typname => 'pg_proc', typlen => '-1', typbyval => 'f', typtype => 'c',
typcategory => 'C', typrelid => 'pg_proc', typinput => 'record_in',
typoutput => 'record_out', typreceive => 'record_recv',
typsend => 'record_send', typalign => 'd', typstorage => 'x' },
{ oid => '83',
{ oid => '83', array_type_oid => '273',
typname => 'pg_class', typlen => '-1', typbyval => 'f', typtype => 'c',
typcategory => 'C', typrelid => 'pg_class', typinput => 'record_in',
typoutput => 'record_out', typreceive => 'record_recv',