Re: [bug] Table not have typarray when created by single user mode

I poked at this patch a bit, and was reminded of the real reason why
we'd skipped making these array types in the first place: it bloats
pg_type noticeably.  As of HEAD, a freshly initialized database has
411 rows in pg_type.  As written this patch results in 543 entries,
or a 32% increase.  That seems like kind of a lot.  On the other hand,
in the big scheme of things maybe it's negligible.  pg_type is still
far from the largest catalog:

postgres=# select relname, relpages from pg_class order by 2 desc;
                    relname                    | relpages
-----------------------------------------------+----------
 pg_proc                                       |       81
 pg_toast_2618                                 |       60
 pg_depend                                     |       59
 pg_attribute                                  |       53
 pg_depend_reference_index                     |       44
 pg_description                                |       36
 pg_depend_depender_index                      |       35
 pg_collation                                  |       32
 pg_proc_proname_args_nsp_index                |       32
 pg_description_o_c_o_index                    |       21
 pg_statistic                                  |       19
 pg_attribute_relid_attnam_index               |       15
 pg_operator                                   |       14
 pg_type                                       |       14  <--- up from 10
 pg_class                                      |       13
 pg_rewrite                                    |       12
 pg_proc_oid_index                             |       11
 ...

However, if we're going to go this far, I think there's a good
case to be made for going all the way and eliminating the policy
of not making array types for system catalogs.  That was never
anything but a wart justified by space savings in pg_type, and
this patch already kills most of the space savings.  If we
drop the system-state test in heap_create_with_catalog altogether,
we end up with 601 initial pg_type entries.  That still leaves
the four bootstrap catalogs without array types, because they are
not created by heap_create_with_catalog; but we can manually add
those too for a total of 605 initial entries.  (That brings initial
pg_type to 14 pages as I show above; I think it was 13 with the
original version of the patch.)

In short, if we're gonna do this, I think we should do it like
the attached.  Or we could do nothing, but there is some appeal
to removing this old inconsistency.

            regards, tom lane

diff --git a/src/backend/catalog/heap.c b/src/backend/catalog/heap.c
index d279842d3c..fd04e82b20 100644
--- a/src/backend/catalog/heap.c
+++ b/src/backend/catalog/heap.c
@@ -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.
-     */
-    if (IsUnderPostmaster && (relkind == RELKIND_RELATION ||
-                              relkind == RELKIND_VIEW ||
-                              relkind == RELKIND_MATVIEW ||
-                              relkind == RELKIND_FOREIGN_TABLE ||
-                              relkind == RELKIND_COMPOSITE_TYPE ||
-                              relkind == RELKIND_PARTITIONED_TABLE))
+     * 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 (!(relkind == RELKIND_SEQUENCE ||
+          relkind == RELKIND_TOASTVALUE ||
+          relkind == RELKIND_INDEX ||
+          relkind == RELKIND_PARTITIONED_INDEX))
         new_array_oid = AssignTypeArrayOid();
 
     /*
diff --git a/src/include/catalog/pg_type.dat b/src/include/catalog/pg_type.dat
index e8be000835..b2cec07416 100644
--- a/src/include/catalog/pg_type.dat
+++ b/src/include/catalog/pg_type.dat
@@ -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',