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